No. Our framework does that. The historical reason is that on some platforms, two sounds playing at once sounded awful and there were limitations to the way we could control sounds, so we arranged to have a currently playing sound be aborted when a new one started.

Yes.

Suppose that while calling doSomething() for each actor during a given tick, we create a new actor. Must we call doSomething() for the new actor on the current tick?

It's you choice whether or not you do. Of course, on the next tick, doSomething() will be called on all actors including that new one.

What can I do to be more confident that my program will build for you when you test it and is not likely to have some flaw that will cause it to crash most of the time when you try to run it?

Run our sanity checker on the Linux server. If it tells you you passed the sanity check, then even if you have a lot of things left unimplemented, we will probably still be able to test those features you have implemented.

Here's what to do:

1. Transfer your Actor.h, Actor.cpp, StudentWorld.h, and StudentWorld.cpp files to the cs32.seas.ucla.edu Linux server.
2. Put those files in a directory where you don't mind if files named GameConstants.h, GameWorld.h, GraphObject.h, Level.h, sanity.cpp, and sanity are created or overwritten.
3. Run the command /usr/local/cs/bin/p3sanity
   This will copy our source files named above into the directory, build an executable named sanity, run it, and either tell you whether your program passes or fails the sanity check or silently crash at some point. (For example, if it gets as far as telling you About to call init for the StudentWorld and then the program ends, something that init did caused it to crash.)

The sanity checker does a simple test to check that loading a level doesn't crash (even if there are objects you haven't yet implemented), the player and walls at least are probably put in the right place, a player probably moves correctly, and cleanup and destruction of the StudentWorld doesn't crash. This is generally enough for us to test your program without it crashing on almost every case.

Why might a program that appears to work for you crash for us most of the time? It's usually because it relies on undefined behavior. A common issue is either your assuming that a pointer you don't explicitly initialize is null or your intending to initialize it to null and forgetting to do so. On your machine, it might happen to have the bit pattern of the null pointer representation, so it appears to work for you, but on our machine, it might not.

If your program built for you on your machine but doesn't build under g32, it may be that you're doing something that is not Standard C++, such as

• Using setw, setfill, etc., without including <iomanip>
• Using an STL algorithm without including <algorithm>

If attempting to make an actor of type X do something crashes and you can't fix the problem before it's time to submit, that could well make even the first call to StudentWorld::move crash for a level that has a type X object in it. In that case, it's best to have the X object's doSomething just return immediately or perhaps after it does only as much as you know doesn't crash.

Why is the sanity checker reporting memory leaks when it finishes?

Your program is allocating objects with new that it's never deallocating with delete. The likeliest causes are one of these:

• When an actor should be removed from the game during a tick, your StudentWorld::move is doing it incorrectly. Solving problem 1c or 1d of Homework 4 should indicate how to fix the problem.
• StudentWorld::cleanUp is not deleting the player and all actors.