Teams
You need to define team positions
and define actions of those positions.
Each team member needs to know their responsibilities.
For ALL, you need to show up to class, show up to meetings,
fill out surveys. BE PREPARED.
Class Philosophy
Software Development is a process with many tools that support that process.
While your product,
i.e., game, is important, the focus of the class is the
development process and experience working with a team.
Front Loaded
This class is unlike any other computer
science class -- it is FRONT Loaded.
What you do in the first 4 weeks will set the tone for the semester.
Start slowly and pay a big price.
Concept Document
A Concept Document is required because your customer
is NOT coming up with
a full conceived
game idea, but rather only a loose education requirement.
Rubrics
There are many many rubrics for the various phases of the class.
There is actually a point:
you cannot skip any of the
aspects of the developement -- they are all important.
In each lab we will: Review Rubrics for Upcoming Deliverables
New Development vs Maintenance
Ever developer that I have talked to responds to the question,
"What do you want students to be able to do?" with: pick up an
existing system, follow the existing development process, and
maintain the code.
Senior Management
That is me. I will try to avoid unilateral decisions,
but I am sure they will happen.
I will also try to keep up with all 4 projects, but alas,
I am sure to get lost.
TRAC
We will use TRAC for each team.
There is a template that each team will start with.
Each team can modify the template, BUT the information must be easily
determinable and accessible by the grutors.
In the end, the ease with which TRAC performs for the grutors is sure to
influence grading. So don't screw up your TRAC.
SVN
We will use SVN (not GIT, RCS, etc.)
No matter how hard we try, each summer we have difficulty finding the
updated repository for each game.
For example, one team create their own GIT library on a dorm server.
Come summer, the server is gone as is the code....
So do not try to convince me that X is better than SVN.
UML
We will use UML, and in particular we will
all use the same system.
Having everyone use the same tool will make it easy for teams to evaluate
each other's work.
This especially comes into play when we are reviewing designs.
PyGame
We will use PyGame as the development world for all the games.
Games will be 2D and single person player games (no net games).
One of our goals
is to be able to execute each game in either the PC or Mac world.
PyGame allows that.
You all have experience with with Python, so startup issues are minimal.
Finally, teams can assist each other in any PyGame issues.
Also, a common environment reduces the startup time during the summer to
maintain these games.
Due Dates
There are many Due Dates for each phase. All Due Dates are on the
Calendar.
The hope is that by having only one specification of the Due Date, we
can avoid conflicting dates and the failure to specify a date becomes
obvious and easy to fix.
Blogs
Piazza blogs.
You will participate in at least two blogs.
Do not moan too much as
I will be a participant on all of them...
Final
There is no final, but during the scheduled final
your ENTIRE team will show up, demonstrate to ME:
TRAC
SVN
Building your game, i.e., get the latest version from SVN, build the game
on a PC and a Mac following your directions.
Executing your game
Lecture vs Project
In an ideal world, one might first present the philosophy and principles of
Software Engineering followed by a project. We are doing both in parallel,
and thus there are times when you will encounter issues within the project
prior to any classroom discussion. Thus, sometimes the classroom lecture
will provide new material, and sometimes the classroom lecture will discuss
issues you have already encountered.
