Introduction

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 proceed button .

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.
Leadership (L): The ability of the candidate to be a project leader. Leaders get no work done. However, a good leader can better take advantage of opportunities and can block 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 proceed button 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 menu bar
The concepts section
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:
- Bug free/Simple Bug/Complex Bug:
- Bug free/Minor Bug/Major Bug:
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.

An Encounter Where You Must Make a Decision

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.

Materials covered in the W3C syllabus include:

Natural Joins

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:

Minus

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 W3C Syllabus doesn't cover this very well:

Not Exists

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.

The W3C Syllabus doesn't cover this very well:

Simple Statistical Functions

The video introduces students to aggregation in SQL and simple statistical functions like sum, min, max, average, etc.