Compare two Makos by placing the same nine fields in a side-by-side sheet: type, rarity, origin, power, ability, personality, likes, friends and rivals. Open both records in the Mako Archive, copy what is actually displayed, and label every cell shown, not shown or not checked. Use power and ability for a capability-focused question, personality and likes for character fit, and friends and rivals for relationship context. A field should affect your choice only when the evidence is visible for both records. If one side is incomplete, keep the comparison provisional and inspect the next profile, room, ability or relationship view instead of filling the gap from memory.
The practical path is Home → Mako Archive → two individual Mako records. The MakoBits home page describes the archive and lists the profile fields that may appear on a record, but the supplied material does not verify a native two-record comparison control. Treat the method below as a manual worksheet: it makes a careful comparison possible without pretending that an absent field says anything about a Mako.
The TRACE method for a fair comparison
A useful comparison is not a single score. It is a short audit that makes the purpose, evidence and next action visible. Use TRACE:
- Target one decision. State what you are trying to decide before reading the records.
- Read both records at the same depth. Inspect the same fields for Mako A and Mako B.
- Assign an evidence state. Distinguish a displayed value from a value you have not yet checked.
- Compare like with like. Place power beside power, likes beside likes and friends beside friends.
- Explore the next connected view. Use the missing or most relevant field to choose what to inspect next.
T — Target one decision
Avoid the vague question “Which Mako is better?” It mixes mechanics, character identity and social connections into one judgement. Write a narrower question such as:
- Which record gives me the clearer ability information to inspect next?
- Which Mako has the personality and likes that fit the character I want to spend time with?
- Which record has the more useful relationship context for my current exploration?
- Which profile needs checking before I can make a responsible comparison?
This does not force a universal preference. It tells you which rows matter. If the question is about power, begin with power and ability. If it is about personality, begin with personality and likes. If it is about relationships, keep friends and rivals as separate evidence rather than treating them as one undifferentiated social score.
R — Read both records at the same depth
Choose the two records first, then inspect them using the same order. A practical order is:
- Type, rarity and origin.
- Power and ability.
- Personality and likes.
- Friends and rivals.
Record the displayed wording, including a qualifier or a blank state. Do not silently translate an unfamiliar value into a more convenient category, and do not treat the order of text in a compact archive excerpt as proof of which field a token belongs to. If one record is open in a detailed view and the other is represented only by a tile or search result, the second record is not checked for the purposes of comparison.
A — Assign an evidence state
Use exactly three states in the worksheet:
| State | Meaning | How to use it |
|---|---|---|
| Shown | The field value is visible in the individual record you inspected. | It may be compared with the same field on the other record. |
| Not shown | You inspected the relevant record view, but no value is displayed for that field. | Treat the field as unresolved; do not convert the absence into a low or negative value. |
| Not checked | You have not inspected that record and field at the same depth yet. | This is a task for the next pass, not evidence about the Mako. |
The distinction matters. “Not shown” describes the record view; “not checked” describes your process. Both are unknowns, but they call for different next actions. A missing value needs a decision about whether more inspection is worthwhile. An unchecked value simply needs the same check performed on the other side.
C — Compare like with like
Use the fields in groups, but never let one group stand in for another:
- Identity context — type, rarity and origin. These help you describe what each record is and how it is labelled. They do not, by themselves, establish a power difference, a personality trait or a social connection.
- Capability context — power and ability. Compare the displayed power entries on equal terms. Read the ability entry alongside power when it is available; do not infer an ability from rarity, origin or the visual design of a record.
- Character context — personality and likes. Capture the wording as presented. A listed like is a record detail, not a reason to assume that every part of the character behaves in the same way.
- Relationship context — friends and rivals. Keep the two lists distinct. A friend entry is not interchangeable with a rival entry, and a listed connection does not establish closeness, importance or a preferred order unless the record says so.
If only one side has a shown value, write a trade-off rather than a conclusion: “Mako A has a displayed ability; Mako B’s ability is not checked.” That sentence is more useful than a made-up value or a forced choice.
E — Explore the next connected view
The comparison should end with a concrete inspection step. Let the unresolved row choose it:
- Missing power or ability → open the individual record and check the capability fields at the same depth.
- Missing personality or likes → inspect the profile view again before making a character-fit judgement.
- Missing friends or rivals → check the relationship details that are actually listed, keeping each type separate.
- A visible change that points beyond the record → inspect the relevant room or scene rather than assuming what the evolution changed.
This makes the worksheet a route through the connected world, not a declaration that one Mako is universally preferable.
The side-by-side worksheet
Copy this matrix into a note for each pair. Replace the bracketed text only with wording that you can see in the relevant record. The state column is mandatory; an empty cell is not a state.
| Field | Mako A value | State | Mako B value | State | Safe comparison use |
|---|---|---|---|---|---|
| Type | [exact displayed value] | [shown / not shown / not checked] | [exact displayed value] | [shown / not shown / not checked] | Describe category or identity context. |
| Rarity | [exact displayed value] | [state] | [exact displayed value] | [state] | Record the label; do not use it as a proxy for power. |
| Origin | [exact displayed value] | [state] | [exact displayed value] | [state] | Compare stated origins only. |
| Power | [exact displayed value] | [state] | [exact displayed value] | [state] | Compare only matched displayed values. |
| Ability | [exact displayed value] | [state] | [exact displayed value] | [state] | Read alongside power when both are available. |
| Personality | [exact displayed value] | [state] | [exact displayed value] | [state] | Compare the recorded descriptions, not imagined behaviour. |
| Likes | [exact displayed value] | [state] | [exact displayed value] | [state] | Note overlap or difference only when both are shown. |
| Friends | [exact displayed value] | [state] | [exact displayed value] | [state] | List connections without inferring their weight. |
| Rivals | [exact displayed value] | [state] | [exact displayed value] | [state] | Keep rivals separate from friends and from dislikes. |
After filling the grid, add three short lines:
- Decision question: what am I trying to decide?
- Supported difference: which same-field difference is actually shown on both sides?
- Next check: which record or connected view will I inspect next?
Do not add a total. A total would make unlike evidence look interchangeable and would give an unchecked field an influence it has not earned.
Decision table: which rows deserve attention?
| Your immediate question | First rows to inspect | A safe statement | If evidence is incomplete |
|---|---|---|---|
| “What can I say about power?” | Power, then ability | “The displayed power entries differ” or “both entries are the same as displayed.” | Mark the missing row and inspect the individual record; do not substitute rarity or type. |
| “Which profile feels closer to my preference?” | Personality, then likes | “The records show different personality or likes entries.” | Keep the choice personal and provisional; do not predict behaviour from a label. |
| “How are these Makos connected?” | Friends and rivals | “These are the connections listed in the records.” | Keep friend and rival rows open until both records have been checked. |
| “Why do the records look different?” | Type, rarity, origin, then the detail fields | “The displayed labels differ in these specific rows.” | Do not infer a cause from a visual difference or from field order in a compact view. |
| “What should I explore next?” | The most relevant unresolved field | “The next useful check is the record/profile/room view that can answer this question.” | Choose inspection, not a winner; leave the conclusion pending. |
Example: Bitto display token versus an unverified second record
This example deliberately demonstrates a partial comparison because the supplied public snapshot does not provide two opened individual records. It shows an archive excerpt beginning with #001 and visibly includes the strings “Comum”, “Robô”, “Bitto” and “Criatura”, followed by labels including Power, Ability, Personality, Likes and Avoids. The excerpt does not establish a clean field-to-token mapping, and it does not supply a second record. Therefore, the raw strings are recorded as display notes rather than assigned to rarity, origin, name or type by guesswork.
| Field | Mako A: supplied archive excerpt | State | Mako B: second slot | State | What the worksheet says |
|---|---|---|---|---|---|
| Record marker | “#001” is visible. | Shown | No second record is supplied. | Not checked | Select a real second record before comparing. |
| Raw display text | “Comum”, “Robô”, “Bitto” and “Criatura” are visible. | Shown | No value supplied. | Not checked | Preserve the strings; confirm their field mapping in the opened record. |
| Type | No record-level mapping is supplied. | Not checked | No value supplied. | Not checked | Do not assign “Criatura” to this row from position alone. |
| Rarity | No record-level mapping is supplied. | Not checked | No value supplied. | Not checked | Do not assign “Comum” to this row from position alone. |
| Origin | No record-level mapping is supplied. | Not checked | No value supplied. | Not checked | Do not assign “Robô” to this row from position alone. |
| Power | The label is visible; a value is not supplied in the excerpt. | Not checked | No value supplied. | Not checked | No power comparison is available. |
| Ability | The label is visible; a value is not supplied in the excerpt. | Not checked | No value supplied. | Not checked | Inspect both individual records. |
| Personality | The label is visible; a value is not supplied in the excerpt. | Not checked | No value supplied. | Not checked | Do not infer personality from the raw tokens. |
| Likes | The label is visible; a value is not supplied in the excerpt. | Not checked | No value supplied. | Not checked | No preference comparison is available. |
| Friends and rivals | No relationship values are supplied. | Not checked | No value supplied. | Not checked | Keep friend and rival rows unresolved. |
The clear next-step choice is open the individual #001 record and one actual second record, then complete the same rows for both. Only after that check can you decide whether the useful next view is the profile, an ability detail, a relationship entry, a room or another connected part of the game. The visible presence of “Avoids” is also not enough to relabel anything as a rival or dislike; preserve it as a separate displayed label until the record defines its role.
Implementation steps for every pair
- Write the decision sentence. For example: “I am comparing these records to decide which detail to explore next.” Keep one purpose per sheet.
- Open Mako A from the Archive. Capture the record marker and exact displayed values. If a field has no value in the opened view, use not shown.
- Open Mako B from the same Archive. Repeat the same field order. If you have not inspected the field, use not checked, not a blank.
- Normalise only the layout, not the evidence. Put the same field names on the same row, but retain the displayed wording. Do not translate or reinterpret an unclear token just to make the columns match.
- Run the two-sided check. For every proposed difference, ask: are both states shown, and were the values read from comparable record views? If not, write “unresolved”.
- Separate observations from preferences. “Power is shown as X on A and Y on B” is an observation. “I would explore A first” is your choice. Keep them on separate lines.
- Route the next inspection. Choose profile for personality or likes context, an ability detail for a capability question, or the relevant relationship or room view when that is the unresolved part. Inspect only what the record actually presents.
- Close the sheet with a bounded conclusion. Use one of three endings: “A is the better fit for my stated question”, “B is the better fit for my stated question”, or “There is not enough matched evidence yet.” The third ending is a valid completion of the process.
A small audit habit prevents most comparison errors: read the two records once for capture, then a second time for interpretation. On the first pass, copy values and states. On the second, apply the decision table. This keeps an attractive label, an unfamiliar translation or a missing field from deciding the comparison before it has been checked.
Limitations
- The supplied first-party snapshot verifies the Mako Archive, individual records and the profile fields that may appear, but it does not verify a built-in side-by-side comparison control. This article’s worksheet is a manual method, not a claimed game feature.
- The public excerpt supplied for the example does not include two complete individual records. It is not safe to name a second Mako, assign the visible tokens to fields, or create a power, personality, likes or relationship difference.
- A field may be absent from a record view or simply not inspected yet. Keep not shown and not checked separate, and never treat either as a low value.
- The available evidence does not establish a universal order between Makos, a numerical meaning for rarity, or any strength, direction or importance for a listed friendship or rivalry. Those interpretations require record-level evidence.
- Record wording may depend on the view or language being inspected. Preserve the displayed wording and confirm the field meaning before comparing unfamiliar terms.
- A comparison cannot answer a question that its chosen fields do not cover. If your real question concerns a room, scene, item or other connected detail, inspect that part directly rather than extending the worksheet beyond its evidence.
FAQ
Can I compare two Makos without a built-in comparison screen?
Yes. Use a personal side-by-side worksheet and inspect both individual records at the same depth. The method is only as reliable as the values you can actually see, so mark everything else not shown or not checked.
Does a higher rarity label mean a Mako has more power?
The supplied evidence lists rarity and power as separate fields but does not establish a rule connecting them. Record both values when shown; do not use one as a substitute for the other.
What if only one Mako has a power or ability value?
Do not compare that row yet. Mark the other cell not shown if its opened record has no displayed value, or not checked if you have not inspected it. Then decide whether opening the missing detail answers your original question.
How should I compare personality and likes?
Copy the displayed personality and likes entries for both records, then describe the difference plainly. Use them to support your own character preference, not to predict behaviour or invent a wider profile.
Should friends and rivals be combined into one relationship score?
No. Keep friends and rivals in separate rows. The records may list connections, but the supplied evidence does not give a common measure for closeness, importance or priority.
Is the TRACE worksheet an in-game feature?
No native two-record control is verified in the supplied material. TRACE is an editorial comparison procedure for reading the Archive carefully and choosing the next detail to inspect.
What is the right conclusion when both records are incomplete?
Say that the comparison is unresolved and name the next check. A clear record of what has not been checked is more useful than a confident conclusion built from missing fields.