6.370 Home: Frequently Asked Questions

Table of Contents

1) General
2) Software
3) Droid Virtual Machines
4) Tournament, Maps, Artifacts, and Goals
5) Droid Abilities and Properties
6) Droid Replication
7) Droid Storage
8) Droid Radio

General

1.5) Is documentation required for a 6.370 submission?

No, only if you want to be considered for an academic prize, and only in your final submission.

1.4) Will failing to beat the reference player affect my transcript/GPA?

No, 6.370 is strictly pass no/record.

1.3) How are team divisions determined for the special prizes?

An undergraduate team consists entirely of undergraduate members, students who have spent four years or less studying at MIT (including 4th year MEng students). All other teams, consisting of one or more graduate students, will be considered graduate teams; a graduate student has spent more than four years studying at MIT (this includes 5th year MEng students). If you are unsure which division your team will be judged in, please contact 6370@mit.edu.

1.2) Can I participate in 6.370 this year if I've already competed in the past?

Yes. You can participate in 6.370 every year we offer it as long as you meet the other requirements listed in the Rules.

1.1) What if I don't know Java?

As long as you know some other object-oriented programming language, like C++, you should be fine, since the contest emphasises algorithmic knowledge that can be implemented in any language. While 6.370 can be a good opportunity to learn Java, keep in mind that competitors with prior Java experience have an advantage.

2) Software

2.2) Can I make suggestions or request features?

Yes; moreover, we will pretend to listen. However, we cannot guarantee that all your suggestions or feature requests will be honoured. We will release a revision almost every night addressing the issues raised that day during the competition.

2.1) Will the contest be open-sourced?

All software for the competition will be released for academic use some time during the second week of the competition. The game server, clients, and DVM will be released under the GPL; the Java classes derived from Sun's implementations will be released under a separate research license. Everything down to the documentation, website mirrors, POV-Ray scripts, and game art will be released at the end of the competition.

3) Droid Virtual Machines

3.4) What errors do we have to catch in our programs?

The abilities themselves shouldn't throw any exceptions as long as you follow the spec for parameter types; if they do, please send us a bug report as described in 3.2. Using active abilities when their conditions are not met will have no effect on game state. Using passive abilities when their conditions are not met returns an empty array. You are responsible for testing the returned array to see if it is null or a zero-length array, or for catching any NullPointerExceptions or ArrayIndexOutOfBoundsExceptions caused by trying to access the return values.

3.3) What classes from the Sun JDK will be available for use in the DVM?

Subsets of the java.lang, java.util, and java.io packages have been re-implemented in pure Java for the DVM from Sun's source code. You can check the contest Javadocs for a detailed listing of what classes and methods you can use.

3.2) What do I do about bugs in the simulator or DVM?

Send us a bug report at 6370-devs@mit.edu with as much information as possible: the returned stack trace, the class/source file causing the problem, and a description of what you were trying to do, like "It doesn't seem to handle final doubles in abstract classes."

3.1) How do you plan to isolate droids from each other, for example, to prevent communication through static (class) variables rather than through the radio?

We will be using Java virtual machines in Java, called Droid Virtual Machines (DVMs) to run each droid's code in a separate runtime environment.

4) Tournament, Maps, Artifacts, and Goals

4.14) Do we automatically win if we destroy the other team?

We will be interpreting the specifications strictly. If you destroy the other team, it will be impossible for them to collect a majority of the artifacts, but the map will not end until you have done so yourself. Which is to say, if you destroy the other team, you are guaranteed to win, but the game will still run until you have collected the majority of artifacts (over half) or time has run out.

4.12) Can droids know the number of unclaimed artifacts left on the map?

Yes, using the GetGoalStatus passive ability in Revision 4.

4.11) Can ore be on water?

Yes, ore may appear on water.

4.10) What is the mountain terrain?

The mountain terrain is impassable to land and water units, but may be travelled by flying units.

4.9) What is the origin of the map?

(0,0) is located in the upper-left corner of the map as displayed in the simulator.

4.8) How can there be a tie if you are competing head to head with one other team and there are odd numbers of artifacts?

There can be ties within the match if both teams recover the same, even number of artifacts, which is less than the total number. In the preliminary match this will mean that a team has failed to beat the reference player and will be disqualified from the finals. In the finals, we will use mean time of recovery as a secondary criterion (time of last artifact acquisition in cycles / number of artifacts currently recovered).

4.7) What do your droids have to do to recover an artifact? Take it back to their starting location?

Your droids must merely store an artifact for it to be considered recovered. However, storing your artifacts in a safe location is a good idea, as enemies can always destroy your droids and steal their artifacts.

4.6) What happens if no team recovers a single artifact before the time limit runs out?

In the finals, both teams will be disqualified, and the match will have no winner. The next match will be a bye for its corresponding player. See the bracket for the specific order of matches. In the preliminaries, the reference player is guaranteed to recover at least one artifact in the time limit given.

4.5) How big are artifacts? Can they be destroyed? How many and where will they be?

Artifacts are 50 stone each. They cannot be destroyed by droids or their abilities. There will be between 5 and 21 (inclusive but odd) artifacts; they can be anywhere on the map except on the mountain terrain. For more information, see the Tournament and Maps section in the specs.

4.4) How many and what type of droids do we start the maps out with?

Your army will start out each tournament map with four droids, one of each type.

4.3) Will starting locations of each army be random? What about the relative starting locations of droids within the same army?

The starting location will be randomly chosen from several strategically equally positions on the map. The Pale River Map given to you as a sample is not representative of the tournament map configuration. Droids in the same army are guaranteed to start out within the same 20x20 span area.

4.2) Will maps be generated randomly?

No, there will be two fixed, predetermined maps used for the preliminary and final tournaments. For more information, see the Tournament and Maps section in the specs.

4.1) What will the map size/goal/time limit be in the preliminary and final tournaments? How much ore will we get and in what distribution?

See the Tournament and Maps section in the specs.

5) Droid Abilities and Properties

5.11) Is it allowed for you to damage a droid/replicant so it can be carried?

Yes, just keep in mind how a replicant receives damage (see 6.9). Also note that mature hemlocks cannot be carried. Even damaged replicants will discard themselves when they become too heavy, and hemlocks will discard themselves when they mature no matter what. The rule about mature hemlocks only applies to the final tournament.

5.10) If a droid uses an active ability and it has no effect, does its timeslice still end?

Yes. In fact, the Yield active ability added in Revision 4.5 exists solely to end your timeslice and have no effect on the game state.

5.9) If a droid is carried, what terrain is it attacked on and what terrains can it now attack?

A carried droid inherits its carrier's terrain, but keeps its old attack abilities. For example, a beetle being carried by a sea dragon can be attacked by other sea dragons, but it still cannot water units. A scion being carried by a beetle cannot be attacked by sea dragons because it is now a flying unit.

5.8) Can you use GET_POSITION/GET_STORAGE on any moniker that you have, even if the droid isn't within sensor range?

No, if the droid whose moniker you specify isn't within range, any calls to passive abilities with that moniker will result in an empty array.

5.7) Do all abilities take 1 cycle to use?

Only active abilities end a DVM's timeslice, and effectively take 1 cycle to use. Calls to passive abilities are considered atomic (1 bytecode instruction) and do not end a DVM's timeslice. However, note that they are idempotent because they do not change game state, and calling it is not useful to call them more than once per cycle.

5.6) What do you mean by a new piece of software in the description of the Reboot ability?

It is simply a string of a Java class name which you have written in your team package.

5.5) Can a droid sense an artifact carried by an enemy?

Yes, using the GetStorage ability on an enemy within sensor range.

5.4) How do droids know if they are near the edge of a map?

The Travel ability will prevent any droid from travelling off the edge of a map. You can get the dimensions of the map as a MapPoint by using the DroidHandle.getMapBounds method.

5.3) How do droids see the map? Does it need to be explored or can droids query about certain points?

Droids can retrieve the terrain moniker (water, air, or mountain) associated with a given MapPoint by using the GetTerrain ability.

5.2) Can beetles fly over water?

Yes, beetles can fly over all terrains on the map.

5.1) When will droid abilities and properties be finalised?

Droid abilities and properties will be finalised after the reference player has been released on 18 January 2002.

6) Droid Replication

6.9) How does a replicant receive damage? Can it be destroyed before it fully assembles?

A replicant can receive damage up to its current hit points (which increases linearly with build time). If a replicant receives damage faster than it can assemble, it can be destroyed.

6.8) Can a replicant receive radio messages?

Yes, the hardware queues up radio messages (up to the maximum buffer size) until the replicant matures and can use the Radio Receive ability.

6.7) What is the moniker of a replicant?

A moniker is assigned to the replicant when it is created, with type Droid, the subtype of its parent, the side of its parent, and a name guaranteed to be unique. The droid keeps this moniker when it matures.

6.6) How many hit points does a replicant have? Does it increase linearly as it assembles?

A replicant starts out with 0 hit points, and the number does increase linearly as the replicant self-assembles.

6.5) Can other droids sense a new replicant? Can replicants attack or be attacked?

Yes, free replicants can be sensed using the Sensor ability and stored replicants can be sensed using the GetStorage ability, like any other physical object. Replicants can be attacked.

6.4) Why doesn't a replicant boot up the primordial software?

Each droid type has a build time, which is the number of cycles between the creation of a replicant and the time it can first boot up the primordial software. Until this build time has elapsed, the replicant is unpowered and cannot run code. See the Droid Properties table for more details.

6.3) Where is a new replicant located?

In a random location one span distant from its parent at the time of replication, at a random angle.

6.2) Does a droid stop to replicate? When it is replicating, can it or its replicant be attacked?

Replication is instantaneous; if a droid is moving when it replicates, it does not stop. As such, both the parent and the replicant can be attacked at any time that they exist in the engine.

6.1) What happens if a droid terminates replication before a replicant finishes assembling? Is the ore used gradually? Is it returned unused?

Since replication is instantenous, the parent pays in ore up front; if the parent does not have enough ore, or the population limit has been reached, attempts to replicate have no effect. Replication cannot be terminated, and if the replicant is destroyed before it completes assembly, its ore is not returned to the parent. See the Replicate ability subsection in the specs for more details.

7) Droid Storage

7.8) Can droids carry replicants? What happens when the replicant becomes too heavy?

Yes, droids can carry replicants. When replicants get too heavy for their carrier, they discard themselves onto the map, at the location of their carrier.

7.7) Is the maximum storage capacity cumulative? For example, can I use a scion to store an artifact and then use a beetle to carry the scion?

Maximum storage capacity is cumulative; it applies to the items a droid store directly, and if any of those items are droids themselves, the limit also applies to their stored items recursively.

7.6) What abilities can a droid use while it is stored?

It can use all of its abilities except Store and Travel.

7.5) What happens to stored items when the storing droid is destroyed?

The stored items fall to the map at the location of the carrying droid when its destroyed. They do not incur any damage as a result.

7.4) Can a droid store an enemy unit?

Theoretically yes. In practice, this may prove difficult.

7.3) Can droids store part of a piece of ore?

Beginning in Revision 4, yes. When a droid tries to store a piece of ore, as many hit points as possible will be coalesced into the droid's existing ore up to its maximum storage capacity. The remaining hit points, if any, will remain with the ore on the map.

7.2) Can multiple droids carry the same artifact to combine their maximum storage capacities?

No. Don't think we don't know what game you're playing.

7.1) Can a droid steal artifacts from an enemy?

Yes, by destroying the enemy first, then storing the artifact when it falls to the map.

8) Droid Radio

8.5) Are radio messages cleared when a droid uses its Radio Receive ability?

Yes.

8.4) What kind of objects can you send over the radio? For example, can we send objects of our own creation?

You may send a single Byte, Character, Short, Integer, Long, Float, Double, String, Moniker, or MapPoint in each use of the Radio Transmit ability. You cannot send objects of your own custom classes due to difficulties of passing them in and out of the DVM. One possible technique is to use Strings as packets, with characters at different positions serving as fields.

8.3) Do radio messages only go to droids in the same army? What prevents an enemy from "jamming" your transmissions?

Radio messages go to any droid within the range of the transmitter. Transmission jamming is a valid technique, but note that the jammer will also interfere with its own communications.

8.2) How does a droid know if its messages are received?

There is no way to verify message receipt built into the engine. If you wish such a feature, you must design it into your software.

8.1) Do radio messages have to be received in the same cycle they were sent?

No, radio messages queued up in each droid's Radio Receive ability up to its maximum buffer size.

Change Log

  • 1.0—14 January 2002:
    Initial revision, only general questions.
  • 4.0—17 January 2002:
    Sections added, revision synchronised with revision of specs and software.
  • 4.1—18 January 2002:
    Questions 3.4, 4.10, 4.11, 4.12, 4.13, 5.8, 5.9, and 7.8 added.
  • 5.0—21 January 2002:
    Questions 5.10 added.
  • 5.5—25 January 2002:
    Questions 1.4, 4.14, 5.11, 6.7, 6.8, 6.9 added.