Welcome to Project Wars. This educational game is designed to help you experience various concepts in project execution.
Your goal is to develop and ship an IT product. To do this, you must produce 10 pieces of integrated
code. The customer will inspect 8 pieces of code. So long as the customer finds no
major bugs in the code, and at most 2 bugs, you win the game. Note these initial numbers can change depending
on various circumstances that occur in the game.
There are two key things you need to produce enough integrated code. The first thing you need to do is hire
competent project team members. The second thing you need to do is make them work. Every week, your project
team will encounter opportunities and problems. With a little luck, how you manage hiring, working, and the opportunities and problems
will determine how successful your project is.
Below is a simple tutorial for Project Wars:
Starting Project Wars
When you start Project Wars, you will see the below page:
Key in a user name and password, and select how much money you wish to allocate to hiring the first hires on your project team, then click the .
Please note a couple of things:
Project Wars is designed to be a simple game and was given 0 budget. It is not very secure! Do not use a password that you are using elsewhere!
While you have a game in progress, keying your username and password allows you to resume the game where you left off. You could (for example) start playing the
game on your desktop PC, then continue playing the same game from an iPad in a cafe with the same username and password.
The username and password cannot include spaces or ampersands(&). This was primarily a convenience to make the game easy to code. Reminder,
the game is not very secure!
Hiring
After the starting screen, or when you select the "hire" option, you will enter the hiring screen, which looks like this:
You will see a list of eligible candidates to hire on the left, and the list of people you have already hired and want to hire on the right.
To select a candidate to hire, click on the candidate on the left. To unselect a candidate, click on the candidate on the right. You cannot unhire
an already hired candidate, but instead must terminate them in the working screen.
Candidates have five statistics. Initially, these statistics have a range of 1-6. However, various encounters can raise or lower these statistics.
Character (C): The personality and integrity of the candidate. Characters with higher character
are resistant to certain kinds of problems.
Specification (S): The ability of the candidate to create specification cards. A specification card
reflects how much of the customer's requirements you understand. A higher specification skill means this candidate can (1) create
more specification cards, and (2) increases the likelihood the specification card is clear. Unclear specification cards increase the
chance of other kinds of errors and expose the project to various problems.
Design (D): The ability of the candidate to create design cards. A design card
reflects how clearly you envision the overall architecture of the solution. A higher design skill means this candidate can (1) create
more design cards, and (2) increases the likelihood the design card is clear. Unclear design cards increase the
chance of other kinds of errors and expose the project to various problems.
Implementation (I): The ability of the candidate to create implementation cards. You need
10 implementation cards (plus adjustments) to complete the game. A higher implementation skill means this candidate can (1) create
more implementation cards, (2) better assist others to create implementation cards, (3) review and identify buggy implementations and (4) debug implementations.
If you have entered from the starting screen, you need to click the on the top righthand corner to continue.
Working
You will spend most of your time on the Working page. The working page is divided into three parts:
The working section, which is subdivided into the:
Hiring section
Commands section
The Menu Section
The menu section has seven options of which five are relevant to playing the game. The other two options- About and Help provide background and support for playing. These options are:
Hire: brings you to the hiring screen. Note when you hire in the working screen, any person you hire
is delayed for two weeks. This reflects that people you hire can't start work immediately, but need time to settle in, and be trained to local procedures.
Work: This allows you to issue commands to your developers.
Submit deliverable: This option only appears if you have sufficient integrated code cards.
When you submit deliverables, one of two things can happen: (1) The customer is happy and you win the game, or (2) The customer is unhappy and complains about your bugs,
in which case, you lose the week.
End turn: This causes your developers to perform the task you assigned them. It also
causes various encounters to occur.
Reset: If you're really stuck, you can reset and start the game all over again.
The concepts section shows you the concepts in play. There are two major parts in the concepts section, the concept summary and the concept cards. The concepts summary shows you the overall effect
of the concept cards in play. It looks like this:
Hovering over the summary will show you which cards are affecting that score and how they are affecting it:
The picture shows the -4 Aid Others penalty is affected by two things. First, there is a default -2 to aiding others. Second, the card "Fundamental Problem" is making the situation
worse by adding an additional -2 penalty.
To the right of the concept summary is the list of actual concept cards in play. Concept cards in green give you a bonus (or don't give you a penalty). Concept cards in red give you a penalty.
You can hover over a concept card to see what it does. For example, hovering over "Fundamental Problem" reveals:
Good (green) concept cards often cost budget. You can click on a good concept to discard it. When you do so, it will turn black. To undispose, click it again. The card is only truly dropped when you end the turn.
Commands
The commands section looks like this:
It has a specification cards section, a design cards section, and a developers' section.
The specification and design cards sections show how many specification and design cards you have and their status. The more specification and design cards you have (up to the game maximum), the
less likely you are to encounter problems. Specification and design cards are either unclear, or of unknown status. The more unclear specification ad design cards you have, the more
likely you are to encounter problems. Cards of unknown status can either be clear, or unclear. You can never determine whether a card is clear. However, unclear cards can be
identified from a review.
In the developers' section, you issue commands. On the left-hand side of this section, there is a leader column. You select who is to lead the project. Ideally, this would
be the developer with the highest leadership score. Leaders can not do any work.
Non-leaders can be issued with the following commands:
Create/Edit Specification: The developer will either create one specification card or swap an unclear specification card for an unknown card for every specification skill the developer has.
The likelihood a specification card is unclear decreases based on the developer's specification skill.
Overtime increases the number of specification cards created by 1.5x (rounded down). Being careful halves the number of cards created (rounded down) but reduces the likelihood of creating
unclear specification cards.
Review Specification: The developer will look through the unknown specification cards looking for unclear cards. The probability
they reveal an unclear card depends on the developer's specification skill.
Create/Edit Design: The developer will either create one design card or swap an unclear design card for an unknown card for every design skill the developer has.
The likelihood a design card is unclear decreases based on the number of clear specification cards and the developer's design skill.
Overtime increases the number of specification cards created by 1.5x (rounded down). Being careful halves the number of cards created (rounded down) but reduces the likelihood of creating
unclear design cards.
Review Design: The developer will look through the unknown design cards looking for unclear cards. The probability
they reveal an unclear card depends on the developer's design skill.
Create Implementation: The developer create one implementation card for every implementation skill the developer has. Unlike specification and
design cards, implementation cards are linked to the developer. This reflects that implementation often carries the signature of the developer. Implementation cards can have a number
of statuses as shown by the below code cards:
Integrated:
A card becomes integrated when the developer issues the "integrate code" command. Once integrated, an implementation
card cannot be debugged. An integrated card is colored green.
Bug free/Simple Bug/Complex Bug:
You can never determine if a code card is bug free. Bug free code and code with unknown bug status are
both colored cyan. A simple bug requires one implementation skill to replace with a card of unknown bug status. A complex bug requires one skill point to shift the bug to the right.
When a complex bug is shifted to the rightmost position, it is transformed into a simple bug.
The likelihood of a bug occurring depends on the number of clear specification and design cards and the developer's skill.
Bug free/Minor Bug/Major Bug:
When you submit deliverables, the customer will randomly select from your integrated code. If the customer
finds even one major bug, the customer will reject the deliverable which will cause you to lose your week. If the customer finds 2 minor bugs,
the customer will likewise reject the deliverable.
Assist Implementation: This works just like create implementation except the developer which performs the command adds code to the developer being assisted.
Assisting an implementation is less efficient than creating an implementation. The loss in productivity is reflected in the "Aid Other" statistic. Note assisting is a viable
strategy, given there are problems that cause all developers to lose code. By assisting others rather than writing your own code, you minimize this effect. For example, if a problem causes all
developers to lose 2 code, and one developer assisted another, only two code is lost. If both developers independently created implementation, 4 code cards would be lost.
The idea of assisting an implementation
simulates the idea of following someone else's coding standards and working based off other peoples' code rather than writing your own.
Review Implementation: Evaluate code to identify bugs. The likelihood of detecting a bug is based on the developer's implementation skill.
Reviewing someone else's code incurs an "Aid Other" penalty, reflecting that it is harder to read others' code than to read your own.
Debug Implementation: Code is debugged from right to left. Complex bugs are shifted one to the right, while simple bugs are replaced
by code of unknown provenance. It is therefore possible to replace a simple bug with a complex bug or a minor bug with a major bug- the debugging made the situation worse, rather than better.
Debugging others' code incurs an "Aid Other" penalty, reflecting that it is harder to read others' code than to read your own.
Package Implementation:
Sets all of an existing developer's code to "integrated".
Terminate: Fire a developer. Note every developer who leaves causes a 1 point morale penalty to the project.
Be careful when you use overtime- this increases the developer's skill, but causes the developer's character to decrease.
Delivery
Delivering integrated code costs you one week. The customer will randomly choose 8 code (plus any additional caused by problems). If
any of these pieces of code contains a major bug or the customer finds 2 code (plus any additional caused by problems), you lose a turn.
Otherwise, you win the game.
Encounters
When you "End Turn" in the Working Screen or the customer finds too many bugs in delivery, you enter the Encounters screen. This screen (1) summarizes your activity for the week and
(2) Tells you of the things you encountered that week. Every day of the week (5 days), you will encounter one thing.
Weekly Activity
Three things are summarized:
Any new hires you made, and when they will appear:
The work your developers did:
Any concepts you lost. Concepts may be lost because you discarded them, or because something else in your project changed. In the below example, the "Fundamental Problem" concept
was dicarded because the project now had sufficient design.
On the top and bottom of the page are a set of arrows. Navigating through those arrows allows you to view your encounters for the week. Encounters can be good or bad. A bad encounter will
cause something bad to happen:
Some bad encounters can be avoided. This requires your developers, leader or project to have certain characteristics:
If the encounter is good, you often just receive the benefits. However, in some cases, a good encounter is avoided because you don't have certain characteristics. In other cases, a good
encounter requires you to pay budget to receive it. If so, the encounter will ask if you want to pay budget.
Tips
Spend money to get as many candidates as you can at the beginning.
Don't hire anyone with a character less than 5. It is better not to hire than to hire a person with a bad character.
Bad character can result in a quit chain- one person quits, which reduces morale, which causes another person to quit, which reduces morale...
Morale reduces both character and leadership. Leaders can't lead when the team is unhappy and stops paying attention to the leader.
The most important person to hire is someone with a high leadership.
The secondmost important person to hire is someone with a high specification skill. It seems like implementation skill does a lot more, but implementation
doesn't affect things further down the chain.
Make sure your design and total number of implementation cards is always less than your number of specification cards until the end of your project.
Put all code with one person with high character and high implementation skill. This is far more efficient than having your individual developers write and debug their own code.
There are special cards that can reduce the impact of "Aid Others". Buy them!
It is often a good idea to have two people with high leadership scores. In the event one leader becomes paralyzed, the other can take over. Conversely, not having a leader
makes your project highly vulnerable to all kinds of problems.
Overtime is best used just before you deliver. Remember, every time you use overtime, you run the risk of your developer quitting, or causing someone else to quit. This does not matter if
you are going to deliver next week.
If you try to implement without requirements or design, the problems will overwhelm you.
Slow and steady wins the race.
Going overbudget creates its own set of problems. If you're just about to deliver, going overbudget is much less risky.
Self Joins
The video here introduces students to joins where a table is summoned more than once.
The concept of aliasing is also introduced.
The video here introduces students to joins where the primary key and foreign key
have exactly the same name and data type. I also advocate for not using this clause
as it leads to sloppy thinking.
Interestingly, the concept is not covered well by W3C, but is covered elsewhere:
The video here introduces students to the minus clause that essentially is the opposite
of a union clause. Note MySQL does not support the minus clause.
The W3C syllabus does not cover minus for some reason.
Not In
The video introduces students to Type I nested queries- queries involving in and not in.
The video introduces students to Type II nested queries- queries involving exists and not exists.
It also introduces students to the problem of three-valued logic and nulls in SQL.
I don't teach the SQL commands to create tables, because (1) they vary considerably across
commercial database platforms and (2) it is more efficient to create tables with a user interface
you should never have to create tables programmatically.
These are exercises for creating tables I use with my students.
.
