The course catalog offers the following overview of this course:
The course serves as an introduction to game programming, and topics include active and passive rendering, sprite animation, collision detection, audio playback, input devices, deployment, and applications of artificial intelligence.
This semester, we will focus our efforts on creating classic arcade games for the Web using PlayN, a platform that will permit us to write game logic in Java that can be deployed as an HTML5 Web application. We will invest the first few weeks of attention learning the basics of game programming and our technology platform. The majority of the semester will be spent working in teams to recreate classic arcade games for the modern Web.
This is a three credit-hour course with three contact-hours per week. Hence, undergraduates should expect to devote six hours of attention to this course outside of class per week, and graduate students, nine.
Note that we will not be studying game design— how ideas for games are generated, how prototypes are built to explore rules systems, how playtesting informs the design process, or what principles tend to create good games. Our focus is on the technology and processes by which games are brought to life in a digital environment. If you are interested in game design, I encourage you to study it, for it is a fascinating field; for our purposes, however, we will be using established designs so that we can focus on concepts of game programming.
The quality of your source code and development process will be evaluated according to the standards established in Robert C. Martin's Clean Code: A Handbook of Agile Software Craftsmanship. These rules will be familiar to undergraduates who have taken CS222 recently; graduate students will need to independently study them as part of their additional effort.
We will use Google Drive to manage and share information. You will need a Google Account, and configuring 2-step verification is strongly recommended. Details on accessing this section's shared drive will be given on Blackboard.
We will use Mercurial for version control. This will be familiar to undergraduates who have taken CS222; graduate students are expected to study it indepenently as part of their additional work. The Hg Init tutorial is strongly recommended, and be sure to specify your username properly—using your BSU email address—as per the Mercurial QuickStart,
Each student is expected to bring a laptop computer to class that is configured for software development. Configuration should be completed within the first first 48 hours of the semester; be ready to develop in class by our second meeting. This configuration minimally includes:
In order for the MercurialEclipse Plug-in to work, you will need to install the Mercurial binaries for your operating system. On Microsoft Windows, these can be downloaded during the plug-in installation process; users of other operating systems will need to install binaries manually. You will not need the CodeBeamer component of the plug-in. Note that the Eclipse configuration sometimes gets confused and uses the wrong information; always check your username before committing.
Should you encounter difficulties with your system configuration, I recommend that you post on the General Discussion forum on the course Blackboard page or contact the friendly neighborhood system administrator.
During the first several weeks of the semester, we will be discussing fundamental techniques of game development. You will be responsible for demonstrating the fruits of your efforts each week with progressively more complex software. The demonstrations will be given during a regular class meeting, and the dates and topics are given below.
|Friday, 8/22||Images||Load and display an image.||0.1|
|Friday, 8/29||Physics||Fire a projectile that follows a parabolic path and interacts with an obstacle or the "wall"||0.2|
|Wednesday, 9/10||Interaction||Add player controls and a simple HUD using TPUI.||0.3|
|Wednesday, 9/17||Architecture||Refactor your demo to use an entity system architecture.||0.4|
All of the code for your demonstrations must be within a single
named course-username-2014, where course is
username is your Ball State username.
For example, if my username was
jdoe and I was enrolled
in CS315, my repository would be
The code used for each demonstration must be tagged in accordance
with the table above.
For each demonstration, you must have a computer that runs your application and a printed copy of relevant source code. You will also be responsible for recording five formal peer evaluations per demo day. The peer evaluation is fundamentally a conversation, and the following rubric is provided to both guide the conversation and to provide a tangible artifact thereof.
|Functional Correctness||Does not run.||Runs but does not meet demo requirements.||Uncertainty regarding meeting the demo requirements.||Meets demo requirements.|
|Code quality||Does not compile or has compiler warnings.||Violates code quality standards||Questionable code quality||Source code is compliant with code quality standards.|
|Aesthetic quality||Does not run.||Does not reflect concern for aesthetics.||Shows some aspects of aesthetic considerations.||Reflects clear design intention and appropriate execution.|
The semester project is the complete and well-executed recreation of a classic video game; choosing one from the golden age of arcade games is recommended. The project will be completed following principles of agile software development. Each project will be completed in four iterations, each of which produces a potentially shippable product increment. That is, each increment should be a complete playable game with a subset of the planned features, and the player should see nothing incomplete within the increment, as is common practice in Scrum.
The anticipated timeline for the project is given in the table below. Deadlines take effect at the beginning of a course meeting. Note that we will have our last meeting during our final exam period, 7:30–9:30 on Friday, December 12.
|Monday, 9/22||Submit concept document by the end of the day|
|Friday, 9/26||Submit proposal document by the end of the day|
|Monday, 10/13||Release 1 deadline (Report due)|
|Monday–Wednesday, 10/13–10/15||Release 1 Presentations|
|Monday, 11/3||Release 2 deadline (Report due)|
|Monday–Wednesday, 11/3–11/5||Release 2 Presentations|
|Friday, 11/21||Release 3 deadline (Report due)|
|Friday–Monday, 11/21–11/24||Release 3 Presentations|
|Friday, 12/12||Release 4 Deadline and Presentations (Report due)|
The project will be completed by teams of three to four students. Each team will submit for approval, through Blackboard, a concept document in Tim Ryan's format. Once this is approved, the team then submits a game proposal, also in Tim Ryan's format, although the market analysis and cost and revenue projections may be omitted. You must include a product backlog consisting of a prioritized list of user stories in Mike Cohn's format; a subset of these should be clearly identified as being undertaken for the first iteration. Note that the concept must be approved before the proposal will be evaluated, and the proposal must be approved before any executable releases will be presented or evaluated.
Each team will give a ten-minute release presentation to showcase their increment. This presentation must address the following, with each component graded according to my triage rubric.
Each increment will be subject to a formal evaluation regarding its functional correctness and technical design. Functional correctness will be evaluated with respect to the selected user stories as well as the stability and usability of the potentially shippable product. Technical design will be evaluated with respect to: the fundamentals of game programming the principles of Clean Code, and other topics introduced in the course. The functional correctness and technical design will be graded using my triage rubric.
At the end of an iteration, each team must submit a release report. This report consists of two parts, each of which will be graded using my triage rubric.
Each team member will conduct a self- and peer-evaluation at the end of each increment using the format below:
|Commitment||Attended all scheduled team meetings or notified the team of absence.||Missed team meetings, with notifications, with enough regularity to be problematic.||Missed one or more team meetings without notifying the team.||Regularly missed team meetings without notifying the team.|
|Participation||Contributed to project planning, implementation, testing, and presentations.||Did not contribute to one of the following: project planning, implementation, testing, and presentations.||Did not contribute to two of the following: planning, implementation, testing, presentation.||Did not contribute to three or more of the following: planning, implementation, testing, presentation.|
|Communication||Clear reports on what has been accomplished, what is in progress, and what stands in the way, thereby facilitating progress.||Sometimes is unclear about what has been done, what is in progress, and what stands in the way, creating minor impediments to progress.||Is regularly unclear about what has been done, what is in progress, and what stands in the way, creating significant impediments to progress.||Communication patterns directly disrupt team progress.|
|Technical contributions||High quality technical contributions that facilitate success of the team.||High quality technical contributions that do not directly facilitate the team's success.||Low quality technical contributions that frequently require redress by other team members.||Low quality technical contributions that inhibit success.|
|Attitude and Leadership||Listens to, shares with, and supports efforts of others, and actively tries to keep the team together.||Listens to, shares with, and supports the efforts of others.||Frequently fails to listen, share, or support teammates.||Displays an antagonism that inhibits team success.|
Each iteration will be graded using the aforementioned rubrics, with the elements weighted as follows:
Each team member will have a contribution score, which is computed as the sum of the medians of each element of the self and peer evaluation, scaled to a 45-point range to match the iteration grade range. A student's individual grade for an iteration will be the minimum of the iteration grade and his or her contribution score.
Your grade will be based on the percent of points earned during the semester. Each peer evaluation in the first five weeks is worth two points, and so 50 points can be earned during this time. Your individual grade for each iteration will be multiplied by the iteration number. Hence, the total number of points that can be earned during the semester is:
50 + (1+2+3+4)*45 = 500
Following my triage rubric, then, your grade will be based on the following table.
|For this grade||Earn up to (%)||Earn up to (points)|
Your learning is commensurate to your participation, and so attendance is expected. You are responsible for your learning regardless of attendance. If you miss a class meeting, you should consult with trusted classmates to ensure you have the appropriate notes. I will not repeat myself unnecessarily over email, during office hours, or by appointment.
Meetings begin at the time scheduled, and you are expected to be ready to begin at this time; late admittance is prohibited.
Students who come to office hours are helped on a first-come, first-served basis; no appointment or prior contact is required. If a student wishes to make an appointment to meet outside of office hours, he or she should email the instructor the request along with several possible meeting times.
All email communication to the instructor should be from a BSU-affiliated address. This policy ensures that senders can be correctly identified and protects your privacy. Email sent from other domains may not be answered.
The instructor may access email through services not affiliated with the University. Please note that such messages necessarily pass through the campus firewall in an unencrypted format, and they may be stored on servers not owned or managed by Ball State University. It is therefore advisable to restrict confidential information to office hours or appointments.
If you are emailing regarding questions in a computer program, it is recommended that you send a copy of the code in question in your email. The preferred method is to copy the code into the body of your message, using plain text and following standard formatting conventions. Alternatively, if the code is in a publicly-readable repository, email the URL.
Although my office telephone number is listed on my Web site, email and face-to-face communication are strongly preferred. I will respond to every student email I receive; I will likely not respond to telephone messages.
Students and faculty are bound by the Student Academic Ethics Policy of the Code of Student Rights and Responsibilities.
It behooves you to be aware of fundamentals of copyright law and the university's intellectual property policies for student-created work.
Want extra feedback on your papers? The Writing Center is a community of Ball State students and faculty who value writing. Come and collaborate with one of our trained peer tutors on any project for any major. The Writing Center is a comfortable, supportive environment for writers from all communities and backgrounds. It is located in Robert Bell 291. To make an appointment, go to http://ballstate.mywconline.com.
If you need course adaptations or accomodations because of a disability, please contact the instructor as soon as possible. Ball State's Disability Services office coordinates services for student with disabilities; documentation of a disability needs to be on file in that office before any accomodations can be provided. Disability Services can be contacted at 765-285-5293 or email@example.com.