Compare commits
9 Commits
factorio_d
...
use_sphinx
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
95779c76ed | ||
|
|
b8b6b1c2da | ||
|
|
309651a644 | ||
|
|
dee8a2aaa9 | ||
|
|
edcfd66658 | ||
|
|
b0119a6a80 | ||
|
|
e35d1f98eb | ||
|
|
727f86c1f1 | ||
|
|
f3e5acbbc4 |
1
.gitignore
vendored
@@ -21,6 +21,7 @@
|
||||
*.archipelago
|
||||
*.apsave
|
||||
|
||||
docs/sphinx/_build/
|
||||
build
|
||||
bundle/components.wxs
|
||||
dist
|
||||
|
||||
@@ -1,343 +0,0 @@
|
||||
|
||||
|
||||
# How do I add a game to Archipelago?
|
||||
This guide is going to try and be a broad summary of how you can do just that.
|
||||
There are two key steps to incorporating a game into Archipelago:
|
||||
- Game Modification
|
||||
- Archipelago Server Integration
|
||||
|
||||
Refer to the following documents as well:
|
||||
- [network protocol.md](https://github.com/ArchipelagoMW/Archipelago/blob/main/docs/network%20protocol.md) for network communication between client and server.
|
||||
- [world api.md](https://github.com/ArchipelagoMW/Archipelago/blob/main/docs/world%20api.md) for documentation on server side code and creating a world package.
|
||||
|
||||
|
||||
# Game Modification
|
||||
One half of the work required to integrate a game into Archipelago is the development of the game client. This is
|
||||
typically done through a modding API or other modification process, described further down.
|
||||
|
||||
As an example, modifications to a game typically include (more on this later):
|
||||
- Hooking into when a 'location check' is completed.
|
||||
- Networking with the Archipelago server.
|
||||
- Optionally, UI or HUD updates to show status of the multiworld session or Archipelago server connection.
|
||||
|
||||
In order to determine how to modify a game, refer to the following sections.
|
||||
|
||||
## Engine Identification
|
||||
This is a good way to make the modding process much easier. Being able to identify what engine a game was made in is critical. The first step is to look at a game's files. Let's go over what some game files might look like. It’s important that you be able to see file extensions, so be sure to enable that feature in your file viewer of choice.
|
||||
Examples are provided below.
|
||||
|
||||
### Creepy Castle
|
||||

|
||||
|
||||
This is the delightful title Creepy Castle, which is a fantastic game that I highly recommend. It’s also your worst-case
|
||||
scenario as a modder. All that’s present here is an executable file and some meta-information that Steam uses. You have
|
||||
basically nothing here to work with. If you want to change this game, the only option you have is to do some pretty nasty
|
||||
disassembly and reverse engineering work, which is outside the scope of this tutorial. Let’s look at some other examples
|
||||
of game releases.
|
||||
|
||||
### Heavy Bullets
|
||||

|
||||
|
||||
Here’s the release files for another game, Heavy Bullets. We see a .exe file, like expected, and a few more files.
|
||||
“hello.txt” is a text file, which we can quickly skim in any text editor. Many games have them in some form, usually
|
||||
with a name like README.txt, and they may contain information about a game, such as a EULA, terms of service, licensing
|
||||
information, credits, and general info about the game. You usually won’t find anything too helpful here, but it never
|
||||
hurts to check. In this case, it contains some credits and a changelog for the game, so nothing too important.
|
||||
“steam_api.dll” is a file you can safely ignore, it’s just some code used to interface with Steam.
|
||||
The directory “HEAVY_BULLETS_Data”, however, has some good news.
|
||||
|
||||

|
||||
|
||||
Jackpot! It might not be obvious what you’re looking at here, but I can instantly tell from this folder’s contents that
|
||||
what we have is a game made in the Unity Engine. If you look in the sub-folders, you’ll seem some .dll files which affirm
|
||||
our suspicions. Telltale signs for this are directories titled “Managed” and “Mono”, as well as the numbered, extension-less
|
||||
level files and the sharedassets files. We’ll tell you a bit about why seeing a Unity game is such good news later,
|
||||
but for now, this is what one looks like. Also keep your eyes out for an executable with a name like UnityCrashHandler,
|
||||
that’s another dead giveaway.
|
||||
|
||||
### Stardew Valley
|
||||

|
||||
|
||||
This is the game contents of Stardew Valley. A lot more to look at here, but some key takeaways.
|
||||
Notice the .dll files which include “CSharp” in their name. This tells us that the game was made in C#, which is good news.
|
||||
More on that later.
|
||||
|
||||
### Gato Roboto
|
||||

|
||||
|
||||
Our last example is the game Gato Roboto. This game is made in GameMaker, which is another green flag to look out for.
|
||||
The giveaway is the file titled "data.win". This immediately tips us off that this game was made in GameMaker.
|
||||
|
||||
This isn't all you'll ever see looking at game files, but it's a good place to start.
|
||||
As a general rule, the more files a game has out in plain sight, the more you'll be able to change.
|
||||
This especially applies in the case of code or script files - always keep a lookout for anything you can use to your
|
||||
advantage!
|
||||
|
||||
## Open or Leaked Source Games
|
||||
As a side note, many games have either been made open source, or have had source files leaked at some point.
|
||||
This can be a boon to any would-be modder, for obvious reasons.
|
||||
Always be sure to check - a quick internet search for "(Game) Source Code" might not give results often, but when it
|
||||
does you're going to have a much better time.
|
||||
|
||||
Be sure never to distribute source code for games that you decompile or find if you do not have express permission to do
|
||||
so, or to redistribute any materials obtained through similar methods, as this is illegal and unethical.
|
||||
|
||||
## Modifying Release Versions of Games
|
||||
However, for now we'll assume you haven't been so lucky, and have to work with only what’s sitting in your install directory.
|
||||
Some developers are kind enough to deliberately leave you ways to alter their games, like modding tools,
|
||||
but these are often not geared to the kind of work you'll be doing and may not help much.
|
||||
|
||||
As a general rule, any modding tool that lets you write actual code is something worth using.
|
||||
|
||||
### Research
|
||||
The first step is to research your game. Even if you've been dealt the worst hand in terms of engine modification,
|
||||
it's possible other motivated parties have concocted useful tools for your game already.
|
||||
Always be sure to search the Internet for the efforts of other modders.
|
||||
|
||||
### Analysis Tools
|
||||
Depending on the game’s underlying engine, there may be some tools you can use either in lieu of or in addition to existing game tools.
|
||||
|
||||
#### [dnSpy](https://github.com/dnSpy/dnSpy/releases)
|
||||
The first tool in your toolbox is dnSpy.
|
||||
dnSpy is useful for opening and modifying code files, like .exe and .dll files, that were made in C#.
|
||||
This won't work for executable files made by other means, and obfuscated code (code which was deliberately made
|
||||
difficult to reverse engineer) will thwart it, but 9 times out of 10 this is exactly what you need.
|
||||
You'll want to avoid opening common library files in dnSpy, as these are unlikely to contain the data you're looking to
|
||||
modify.
|
||||
|
||||
For Unity games, the file you’ll want to open will be the file (Data Folder)/Managed/Assembly-CSharp.dll, as pictured below:
|
||||
|
||||

|
||||
|
||||
This file will contain the data of the actual game.
|
||||
For other C# games, the file you want is usually just the executable itself.
|
||||
|
||||
With dnSpy, you can view the game’s C# code, but the tool isn’t perfect.
|
||||
Although the names of classes, methods, variables, and more will be preserved, code structures may not remain entirely intact. This is because compilers will often subtly rewrite code to be more optimal, so that it works the same as the original code but uses fewer resources. Compiled C# files also lose comments and other documentation.
|
||||
|
||||
#### [UndertaleModTool](https://github.com/krzys-h/UndertaleModTool/releases)
|
||||
This is currently the best tool for modifying games made in GameMaker, and supports games made in both GMS 1 and 2.
|
||||
It allows you to modify code in GML, if the game wasn't made with the wrong compiler (usually something you don't have
|
||||
to worry about).
|
||||
|
||||
You'll want to open the data.win file, as this is where all the goods are kept.
|
||||
Like dnSpy, you won’t be able to see comments.
|
||||
In addition, you will be able to see and modify many hidden fields on items that GameMaker itself will often hide from
|
||||
creators.
|
||||
|
||||
Fonts in particular are notoriously complex, and to add new sprites you may need to modify existing sprite sheets.
|
||||
|
||||
#### [CheatEngine](https://cheatengine.org/)
|
||||
CheatEngine is a tool with a very long and storied history.
|
||||
Be warned that because it performs live modifications to the memory of other processes, it will likely be flagged as
|
||||
malware (because this behavior is most commonly found in malware and rarely used by other programs).
|
||||
If you use CheatEngine, you need to have a deep understanding of how computers work at the nuts and bolts level,
|
||||
including binary data formats, addressing, and assembly language programming.
|
||||
|
||||
The tool itself is highly complex and even I have not yet charted its expanses.
|
||||
However, it can also be a very powerful tool in the right hands, allowing you to query and modify gamestate without ever
|
||||
modifying the actual game itself.
|
||||
In theory it is compatible with any piece of software you can run on your computer, but there is no "easy way" to do
|
||||
anything with it.
|
||||
|
||||
### What Modifications You Should Make to the Game
|
||||
We talked about this briefly in [Game Modification](#game-modification) section.
|
||||
The next step is to know what you need to make the game do now that you can modify it. Here are your key goals:
|
||||
- Modify the game so that checks are shuffled
|
||||
- Know when the player has completed a check, and react accordingly
|
||||
- Listen for messages from the Archipelago server
|
||||
- Modify the game to display messages from the Archipelago server
|
||||
- Add interface for connecting to the Archipelago server with passwords and sessions
|
||||
- Add commands for manually rewarding, re-syncing, forfeiting, and other actions
|
||||
|
||||
To elaborate, you need to be able to inform the server whenever you check locations, print out messages that you receive
|
||||
from the server in-game so players can read them, award items when the server tells you to, sync and re-sync when necessary,
|
||||
avoid double-awarding items while still maintaining game file integrity, and allow players to manually enter commands in
|
||||
case the client or server make mistakes.
|
||||
|
||||
Refer to the [Network Protocol documentation](./network%20protocol.md) for how to communicate with Archipelago's servers.
|
||||
|
||||
## But my Game is a console game. Can I still add it?
|
||||
That depends – what console?
|
||||
|
||||
### My Game is a recent game for the PS4/Xbox-One/Nintendo Switch/etc
|
||||
Most games for recent generations of console platforms are inaccessible to the typical modder. It is generally advised
|
||||
that you do not attempt to work with these games as they are difficult to modify and are protected by their copyright
|
||||
holders. Most modern AAA game studios will provide a modding interface or otherwise deny modifications for their console games.
|
||||
|
||||
### My Game isn’t that old, it’s for the Wii/PS2/360/etc
|
||||
This is very complex, but doable.
|
||||
If you don't have good knowledge of stuff like Assembly programming, this is not where you want to learn it.
|
||||
There exist many disassembly and debugging tools, but more recent content may have lackluster support.
|
||||
|
||||
### My Game is a classic for the SNES/Sega Genesis/etc
|
||||
That’s a lot more feasible.
|
||||
There are many good tools available for understanding and modifying games on these older consoles, and the emulation
|
||||
community will have figured out the bulk of the console’s secrets.
|
||||
Look for debugging tools, but be ready to learn assembly.
|
||||
Old consoles usually have their own unique dialects of ASM you’ll need to get used to.
|
||||
|
||||
Also make sure there’s a good way to interface with a running emulator, since that’s the only way you can connect these
|
||||
older consoles to the Internet.
|
||||
There are also hardware mods and flash carts, which can do the same things an emulator would when connected to a computer,
|
||||
but these will require the same sort of interface software to be written in order to work properly - from your perspective
|
||||
the two won't really look any different.
|
||||
|
||||
### My Game is an exclusive for the Super Baby Magic Dream Boy. It’s this console from the Soviet Union that-
|
||||
Unless you have a circuit schematic for the Super Baby Magic Dream Boy sitting on your desk, no.
|
||||
Obscurity is your enemy – there will likely be little to no emulator or modding information, and you’d essentially be
|
||||
working from scratch.
|
||||
|
||||
## How to Distribute Game Modifications
|
||||
**NEVER EVER distribute anyone else's copyrighted work UNLESS THEY EXPLICITLY GIVE YOU PERMISSION TO DO SO!!!**
|
||||
|
||||
This is a good way to get any project you're working on sued out from under you.
|
||||
The right way to distribute modified versions of a game's binaries, assuming that the licensing terms do not allow you
|
||||
to copy them wholesale, is as patches.
|
||||
|
||||
There are many patch formats, which I'll cover in brief. The common theme is that you can’t distribute anything that
|
||||
wasn't made by you. Patches are files that describe how your modified file differs from the original one, thus avoiding
|
||||
the issue of distributing someone else’s original work.
|
||||
|
||||
Users who have a copy of the game just need to apply the patch, and those who don’t are unable to play.
|
||||
|
||||
### Patches
|
||||
|
||||
#### IPS
|
||||
IPS patches are a simple list of chunks to replace in the original to generate the output. It is not possible to encode
|
||||
moving of a chunk, so they may inadvertently contain copyrighted material and should be avoided unless you know it's
|
||||
fine.
|
||||
|
||||
#### UPS, BPS, VCDIFF (xdelta), bsdiff
|
||||
Other patch formats generate the difference between two streams (delta patches) with varying complexity. This way it is
|
||||
possible to insert bytes or move chunks without including any original data. Bsdiff is highly optimized and includes
|
||||
compression, so this format is used by APBP.
|
||||
|
||||
Only a bsdiff module is integrated into AP. If the final patch requires or is based on any other patch, convert them to
|
||||
bsdiff or APBP before adding it to the AP source code as "basepatch.bsdiff4" or "basepatch.apbp".
|
||||
|
||||
#### APBP Archipelago Binary Patch
|
||||
Starting with version 4 of the APBP format, this is a ZIP file containing metadata in `archipelago.json` and additional
|
||||
files required by the game / patching process. For ROM-based games the ZIP will include a `delta.bsdiff4` which is the
|
||||
bsdiff between the original and the randomized ROM.
|
||||
|
||||
To make using APBP easy, they can be generated by inheriting from `Patch.APDeltaPatch`.
|
||||
|
||||
### Mod files
|
||||
Games which support modding will usually just let you drag and drop the mod’s files into a folder somewhere.
|
||||
Mod files come in many forms, but the rules about not distributing other people's content remain the same.
|
||||
They can either be generic and modify the game using a seed or `slot_data` from the AP websocket, or they can be
|
||||
generated per seed.
|
||||
|
||||
If the mod is generated by AP and is installed from a ZIP file, it may be possible to include APBP metadata for easy
|
||||
integration into the Webhost by inheriting from `Patch.APContainer`.
|
||||
|
||||
|
||||
## Archipelago Integration
|
||||
Integrating a randomizer into Archipelago involves a few steps.
|
||||
There are several things that may need to be done, but the most important is to create an implementation of the
|
||||
`World` class specific to your game. This implementation should exist as a Python module within the `worlds` folder
|
||||
in the Archipelago file structure.
|
||||
|
||||
This encompasses most of the data for your game – the items available, what checks you have, the logic for reaching those
|
||||
checks, what options to offer for the player’s yaml file, and the code to initialize all this data.
|
||||
|
||||
Here’s an example of what your world module can look like:
|
||||
|
||||

|
||||
|
||||
The minimum requirements for a new archipelago world are the package itself (the world folder containing a file named `__init__.py`),
|
||||
which must define a `World` class object for the game with a game name, create an equal number of items and locations with rules,
|
||||
a win condition, and at least one `Region` object.
|
||||
|
||||
Let's give a quick breakdown of what the contents for these files look like.
|
||||
This is just one example of an Archipelago world - the way things are done below is not an immutable property of Archipelago.
|
||||
|
||||
### Items.py
|
||||
This file is used to define the items which exist in a given game.
|
||||
|
||||

|
||||
|
||||
Some important things to note here. The center of our Items.py file is the item_table, which individually lists every
|
||||
item in the game and associates them with an ItemData.
|
||||
|
||||
This file is rather skeletal - most of the actual data has been stripped out for simplicity.
|
||||
Each ItemData gives a numeric ID to associate with the item and a boolean telling us whether the item might allow the
|
||||
player to do more than they would have been able to before.
|
||||
|
||||
Next there's the item_frequencies. This simply tells Archipelago how many times each item appears in the pool.
|
||||
Items that appear exactly once need not be listed - Archipelago will interpret absence from this dictionary as meaning
|
||||
that the item appears once.
|
||||
|
||||
Lastly, note the `lookup_id_to_name` dictionary, which is typically imported and used in your Archipelago `World`
|
||||
implementation. This is how Archipelago is told about the items in your world.
|
||||
|
||||
### Locations.py
|
||||
This file lists all locations in the game.
|
||||
|
||||

|
||||
|
||||
First is the achievement_table. It lists each location, the region that it can be found in (more on regions later),
|
||||
and a numeric ID to associate with each location.
|
||||
|
||||
The exclusion table is a series of dictionaries which are used to exclude certain checks from the pool of progression
|
||||
locations based on user settings, and the events table associates certain specific checks with specific items.
|
||||
|
||||
`lookup_id_to_name` is also present for locations, though this is a separate dictionary, to be clear.
|
||||
|
||||
### Options.py
|
||||
This file details options to be searched for in a player's YAML settings file.
|
||||
|
||||

|
||||
|
||||
There are several types of option Archipelago has support for.
|
||||
In our case, we have three separate choices a player can toggle, either On or Off.
|
||||
You can also have players choose between a number of predefined values, or have them provide a numeric value within a
|
||||
specified range.
|
||||
|
||||
### Regions.py
|
||||
This file contains data which defines the world's topology.
|
||||
In other words, it details how different regions of the game connect to each other.
|
||||
|
||||

|
||||
|
||||
`terraria_regions` contains a list of tuples.
|
||||
The first element of the tuple is the name of the region, and the second is a list of connections that lead out of the region.
|
||||
|
||||
`mandatory_connections` describe where the connection leads.
|
||||
|
||||
Above this data is a function called `link_terraria_structures` which uses our defined regions and connections to create
|
||||
something more usable for Archipelago, but this has been left out for clarity.
|
||||
|
||||
### Rules.py
|
||||
This is the file that details rules for what players can and cannot logically be required to do, based on items and settings.
|
||||
|
||||

|
||||
|
||||
This is the most complicated part of the job, and is one part of Archipelago that is likely to see some changes in the future.
|
||||
The first class, called `TerrariaLogic`, is an extension of the `LogicMixin` class.
|
||||
This is where you would want to define methods for evaluating certain conditions, which would then return a boolean to
|
||||
indicate whether conditions have been met. Your rule definitions should start with some sort of identifier to delineate it
|
||||
from other games, as all rules are mixed together due to `LogicMixin`. In our case, `_terraria_rule` would be a better name.
|
||||
|
||||
The method below, `set_rules()`, is where you would assign these functions as "rules", using lambdas to associate these
|
||||
functions or combinations of them (or any other code that evaluates to a boolean, in my case just the placeholder `True`)
|
||||
to certain tasks, like checking locations or using entrances.
|
||||
|
||||
### \_\_init\_\_.py
|
||||
This is the file that actually extends the `World` class, and is where you expose functionality and data to Archipelago.
|
||||
|
||||

|
||||
|
||||
This is the most important file for the implementation, and technically the only one you need, but it's best to keep this
|
||||
file as short as possible and use other script files to do most of the heavy lifting.
|
||||
If you've done things well, this will just be where you assign everything you set up in the other files to their associated
|
||||
fields in the class being extended.
|
||||
|
||||
This is also a good place to put game-specific quirky behavior that needs to be managed, as it tends to make things a bit
|
||||
cluttered if you put these things elsewhere.
|
||||
|
||||
The various methods and attributes are documented in `/worlds/AutoWorld.py[World]` and
|
||||
[world api.md](https://github.com/ArchipelagoMW/Archipelago/blob/main/docs/world%20api.md),
|
||||
though it is also recommended to look at existing implementations to see how all this works first-hand.
|
||||
Once you get all that, all that remains to do is test the game and publish your work.
|
||||
108
docs/sphinx/AddingArchipelagoIntegration.md
Normal file
@@ -0,0 +1,108 @@
|
||||
# Archipelago Integration
|
||||
Integrating a randomizer into Archipelago involves a few steps.
|
||||
There are several things that may need to be done, but the most important is to create an implementation of the
|
||||
`World` class specific to your game. This implementation should exist as a Python module within the `worlds` folder
|
||||
in the Archipelago file structure.
|
||||
|
||||
This encompasses most of the data for your game – the items available, what checks you have, the logic for reaching those
|
||||
checks, what options to offer for the player’s yaml file, and the code to initialize all this data.
|
||||
|
||||
Here’s an example of what your world module can look like:
|
||||
|
||||

|
||||
|
||||
The minimum requirements for a new archipelago world are the package itself (the world folder containing a file named `__init__.py`),
|
||||
which must define a `World` class object for the game with a game name, create an equal number of items and locations with rules,
|
||||
a win condition, and at least one `Region` object.
|
||||
|
||||
Let's give a quick breakdown of what the contents for these files look like.
|
||||
This is just one example of an Archipelago world - the way things are done below is not an immutable property of Archipelago.
|
||||
|
||||
## Items.py
|
||||
This file is used to define the items which exist in a given game.
|
||||
|
||||

|
||||
|
||||
Some important things to note here. The center of our Items.py file is the item_table, which individually lists every
|
||||
item in the game and associates them with an ItemData.
|
||||
|
||||
This file is rather skeletal - most of the actual data has been stripped out for simplicity.
|
||||
Each ItemData gives a numeric ID to associate with the item and a boolean telling us whether the item might allow the
|
||||
player to do more than they would have been able to before.
|
||||
|
||||
Next there's the item_frequencies. This simply tells Archipelago how many times each item appears in the pool.
|
||||
Items that appear exactly once need not be listed - Archipelago will interpret absence from this dictionary as meaning
|
||||
that the item appears once.
|
||||
|
||||
Lastly, note the `lookup_id_to_name` dictionary, which is typically imported and used in your Archipelago `World`
|
||||
implementation. This is how Archipelago is told about the items in your world.
|
||||
|
||||
## Locations.py
|
||||
This file lists all locations in the game.
|
||||
|
||||

|
||||
|
||||
First is the achievement_table. It lists each location, the region that it can be found in (more on regions later),
|
||||
and a numeric ID to associate with each location.
|
||||
|
||||
The exclusion table is a series of dictionaries which are used to exclude certain checks from the pool of progression
|
||||
locations based on user settings, and the events table associates certain specific checks with specific items.
|
||||
|
||||
`lookup_id_to_name` is also present for locations, though this is a separate dictionary, to be clear.
|
||||
|
||||
## Options.py
|
||||
This file details options to be searched for in a player's YAML settings file.
|
||||
|
||||

|
||||
|
||||
There are several types of option Archipelago has support for.
|
||||
In our case, we have three separate choices a player can toggle, either On or Off.
|
||||
You can also have players choose between a number of predefined values, or have them provide a numeric value within a
|
||||
specified range.
|
||||
|
||||
## Regions.py
|
||||
This file contains data which defines the world's topology.
|
||||
In other words, it details how different regions of the game connect to each other.
|
||||
|
||||

|
||||
|
||||
`terraria_regions` contains a list of tuples.
|
||||
The first element of the tuple is the name of the region, and the second is a list of connections that lead out of the region.
|
||||
|
||||
`mandatory_connections` describe where the connection leads.
|
||||
|
||||
Above this data is a function called `link_terraria_structures` which uses our defined regions and connections to create
|
||||
something more usable for Archipelago, but this has been left out for clarity.
|
||||
|
||||
## Rules.py
|
||||
This is the file that details rules for what players can and cannot logically be required to do, based on items and settings.
|
||||
|
||||

|
||||
|
||||
This is the most complicated part of the job, and is one part of Archipelago that is likely to see some changes in the future.
|
||||
The first class, called `TerrariaLogic`, is an extension of the `LogicMixin` class.
|
||||
This is where you would want to define methods for evaluating certain conditions, which would then return a boolean to
|
||||
indicate whether conditions have been met. Your rule definitions should start with some sort of identifier to delineate it
|
||||
from other games, as all rules are mixed together due to `LogicMixin`. In our case, `_terraria_rule` would be a better name.
|
||||
|
||||
The method below, `set_rules()`, is where you would assign these functions as "rules", using lambdas to associate these
|
||||
functions or combinations of them (or any other code that evaluates to a boolean, in my case just the placeholder `True`)
|
||||
to certain tasks, like checking locations or using entrances.
|
||||
|
||||
## \_\_init\_\_.py
|
||||
This is the file that actually extends the `World` class, and is where you expose functionality and data to Archipelago.
|
||||
|
||||

|
||||
|
||||
This is the most important file for the implementation, and technically the only one you need, but it's best to keep this
|
||||
file as short as possible and use other script files to do most of the heavy lifting.
|
||||
If you've done things well, this will just be where you assign everything you set up in the other files to their associated
|
||||
fields in the class being extended.
|
||||
|
||||
This is also a good place to put game-specific quirky behavior that needs to be managed, as it tends to make things a bit
|
||||
cluttered if you put these things elsewhere.
|
||||
|
||||
The various methods and attributes are documented in `/worlds/AutoWorld.py[World]` and
|
||||
[world api.md](https://github.com/ArchipelagoMW/Archipelago/blob/main/docs/world%20api.md),
|
||||
though it is also recommended to look at existing implementations to see how all this works first-hand.
|
||||
Once you get all that, all that remains to do is test the game and publish your work.
|
||||
225
docs/sphinx/AddingGames.md
Normal file
@@ -0,0 +1,225 @@
|
||||
# Adding Games to Archipelago
|
||||
This guide is going to try and be a broad summary of what is required to add a game integration to Archipelago.
|
||||
|
||||
This guide is not an in-depth tutorial on video game modification nor is it a getting started guide to software or
|
||||
video game development. The intent is to provide information, tips, and tools, to assist a would-be modder in adding a
|
||||
game integration to Archipelago.
|
||||
|
||||
There are two key steps to incorporating a game into Archipelago:
|
||||
- Game Modification
|
||||
- Archipelago Server Integration
|
||||
|
||||
This document covers game modification. Information on creating the Archipelago server integration may be found in the
|
||||
[Adding Archipelago Integration](./AddingArchipelagoIntegration.md).
|
||||
|
||||
## Game Modification
|
||||
One half of the work required to integrate a game into Archipelago is the development of the game client. This is
|
||||
typically done through a modding API or other modification process, this is described further down.
|
||||
|
||||
As an example, modifications to a game typically include:
|
||||
- Hooking into when a "location check" is completed.
|
||||
- Networking with the Archipelago server.
|
||||
- Optionally, UI or HUD updates to show status of the multiworld session or Archipelago server connection.
|
||||
|
||||
### Engine Identification
|
||||
This is a good way to make the modding process much easier. Being able to identify what engine a game was made in is
|
||||
critical. The first step is to look at a game's files. Let's go over what some game files might look like. It’s
|
||||
important that you be able to see file extensions, so be sure to enable that feature in your file viewer of choice.
|
||||
|
||||
#### Examples
|
||||
##### Proprietary Game Engine
|
||||

|
||||
|
||||
This is the game _Creepy Castle_. It’s your worst-case scenario as a modder. All that’s present here is an executable
|
||||
file and some meta-information that Steam uses. You have basically nothing here to work with. If you want to change
|
||||
this game, the only option you have is to do some pretty nasty disassembly and reverse engineering work, which is
|
||||
outside the scope of this tutorial.
|
||||
|
||||
##### Unity Game Engine
|
||||

|
||||
|
||||
Here’s the release files for another game, _Heavy Bullets_. We see a .exe file, like expected, and a few more files.
|
||||
`hello.txt` is a text file, which we can quickly skim in any text editor. Many games have text files in their directories
|
||||
in some form, usually with a name like `README.txt`. They may contain information about a game, such as a EULA, terms
|
||||
of service, licensing information, credits, or other general info about the game. You typically won’t find anything too
|
||||
helpful here, but it never hurts to check.
|
||||
|
||||
In this case, it contains some credits and a changelog for the game, so nothing too important.
|
||||
`steam_api.dll` is a file you can safely ignore, it’s just some code used to interface with Steam.
|
||||
The directory `HEAVY_BULLETS_Data`, however, has some good news.
|
||||
|
||||

|
||||
|
||||
The contents of the `HEAVY_BULLETS_Data` directory follow the pattern typically used by the Unity game engine.
|
||||
If you look in the sub-folders, you’ll seem some .dll files which affirm our suspicions. Telltale signs for this are
|
||||
directories titled `Managed` and `Mono`, as well as the numbered, extension-less level files and the sharedassets files.
|
||||
Also keep your eyes out for an executable with a name like UnityCrashHandler, that’s another dead giveaway.
|
||||
|
||||
##### XNA/FNA
|
||||

|
||||
|
||||
This is the game contents of _Stardew Valley_.
|
||||
A lot more to look at here, but there are some key takeaways. Notice the .dll files which include “CSharp” in their
|
||||
name. Also notice the `Content`. These signs point to a game based on the .NET framework and many games following this
|
||||
style will use the XNA game framework as the base to build their game from.
|
||||
|
||||
##### Gato Roboto
|
||||

|
||||
|
||||
Our last example is the game _Gato Roboto_. Notice the file titled `data.win`. This immediately tips us off that this
|
||||
game was made in GameMaker.
|
||||
|
||||
### Open or Leaked Source Games
|
||||
As a side note, many games have either been made open source, or have had source files leaked at some point.
|
||||
This can be a boon to any would-be modder, for obvious reasons.
|
||||
Always be sure to check - a quick internet search for "(Game) Source Code" might not give results often, but when it
|
||||
does you're going to have a much better time.
|
||||
|
||||
Be sure **never** to distribute source code for games that you decompile or find if you do not have express permission
|
||||
from the author to do so, nor to redistribute any materials obtained through similar methods, as this is illegal and
|
||||
unethical.
|
||||
|
||||
### Modifying Release Versions of Games
|
||||
Some developers are kind enough to deliberately leave you ways to alter their games, like modding tools, but these are
|
||||
often not geared to the kind of work you'll be doing and may not help much. This is usually assessed on a case-by-case
|
||||
basis. Games with large modding communities typically grow around the tooling a developer provides or they grow around
|
||||
the fact that the game is easy to modify in the first place.
|
||||
|
||||
As a general rule, any modding tool that lets you write actual code is something worth using.
|
||||
|
||||
### Creating the Mod
|
||||
#### Research
|
||||
The first step is to research your game. Even if you've been dealt the worst hand in terms of engine modification,
|
||||
it's possible other motivated parties have concocted useful tools for your game already.
|
||||
Always be sure to search the Internet for the efforts of other modders.
|
||||
|
||||
#### Analysis Tools
|
||||
Depending on the game’s underlying engine, there may be some tools you can use either in lieu of or in addition to
|
||||
existing game tools.
|
||||
|
||||
##### ILSpy
|
||||
You can download ILSpy and see more info about it on the [ILSpy GitHub repository homepage](https://github.com/icsharpcode/ILSpy).
|
||||
|
||||
The first tool in your toolbox is ILSpy. ILSpy is a .NET decompiler. The purpose of this program is to take a compiled
|
||||
.NET assembly (.DLL or .EXE file) and turn it back into human-readable source code. A file is a .NET assembly when it
|
||||
was created through the compilation of any programming language targeting the .NET runtime. Usually, the programming
|
||||
language in question is C# (C Sharp).
|
||||
|
||||
Unity games are a combination of native code (compiled in a "native language" such as C++) and .NET code. Most game
|
||||
developers will write the bulk of their code as C# and this will be compiled by Unity into .NET assemblies. Those files
|
||||
may then be decompiled with ILSpy to allow you to see the original source code of the game.
|
||||
|
||||
For Unity games, the file you’ll typically want to open will be the file (Data Folder)/Managed/Assembly-CSharp.dll, as
|
||||
pictured below:
|
||||
|
||||

|
||||
|
||||
For other .NET based games, which are not made in Unity, the file you want is usually just the executable itself.
|
||||
|
||||
Although the names of classes, methods, variables, and more will be preserved, code structures may not remain entirely
|
||||
intact. This is because compilers will often subtly rewrite code to be more optimal, so that it works the same as the
|
||||
original code but uses fewer resources. Compiled C# files also lose comments and other documentation.
|
||||
|
||||
##### UndertaleModTool
|
||||
You can download and find more info on UndertaleModTool on the [UndertaleModTool GitHub repository homepage](https://github.com/krzys-h/UndertaleModTool/releases).
|
||||
This is currently the best tool for modifying games made in GameMaker, and supports games made in both GameMaker Studio
|
||||
1 and 2. It allows you to modify code in GameMaker Language (GML).
|
||||
|
||||
Use the tool to open the `data.win` file to see game data and code.
|
||||
Like ILSpy, you won’t be able to see comments.
|
||||
In addition, you will be able to see and modify many hidden fields on items that GameMaker itself will often hide from
|
||||
creators.
|
||||
|
||||
Fonts in particular are notoriously complex, and to add new sprites you may need to modify existing sprite sheets.
|
||||
|
||||
#### What Modifications You Should Make to the Game
|
||||
We talked about this briefly in [Game Modification](#game-modification) section.
|
||||
The next step is to know what you need to make the game do now that you can modify it. Here are your key goals:
|
||||
- Modify the game so that checks are shuffled
|
||||
- Know when the player has completed a check, and react accordingly
|
||||
- Listen for messages from the Archipelago server
|
||||
- Modify the game to display messages from the Archipelago server
|
||||
- Add interface for connecting to the Archipelago server with passwords and sessions
|
||||
- Add commands for manually rewarding, re-syncing, forfeiting, and other actions
|
||||
|
||||
To elaborate, you need to be able to inform the server whenever you check locations, print out messages that you receive
|
||||
from the server in-game so players can read them, award items when the server tells you to, sync and re-sync when necessary,
|
||||
avoid double-awarding items while still maintaining game file integrity, and allow players to manually enter commands in
|
||||
case the client or server make mistakes.
|
||||
|
||||
Refer to the [Network Protocol documentation](../NetworkProtocol.md) for how to communicate with Archipelago's servers.
|
||||
|
||||
### Modifying Console Games
|
||||
#### My Game is a recent game for the PS4/Xbox-One/Nintendo Switch/etc
|
||||
Most games for recent generations of console platforms are inaccessible to the typical modder. It is generally advised
|
||||
that you do not attempt to work with these games as they are difficult to modify and are protected by their copyright
|
||||
holders. Most modern AAA game studios will provide a modding interface or otherwise deny modifications for their console
|
||||
games.
|
||||
|
||||
There is some traction on this changing as studios are finding ways to include game modifications in console games.
|
||||
|
||||
#### My Game isn’t that old, it’s for the Wii/PS2/360/etc
|
||||
This is very complex, but doable.
|
||||
It is typically necessary to use Assembly (ASM) to modify these games.
|
||||
If you don't have good knowledge of stuff like Assembly programming, this is not where you want to learn it.
|
||||
There exist many disassembly and debugging tools, but more recent content may have lackluster support.
|
||||
|
||||
#### My Game is a classic for the SNES/Sega Genesis/etc
|
||||
That’s a lot more feasible.
|
||||
There are many good tools available for understanding and modifying games on these older consoles, and the emulation
|
||||
community will have figured out the bulk of the console’s secrets. Look for debugging tools, but be ready to learn
|
||||
assembly. Old consoles usually have their own unique dialects of ASM you’ll need to get used to.
|
||||
|
||||
Also make sure there’s a good way to interface with a running emulator, since that’s the only way you can connect these
|
||||
older consoles to the internet. There are also hardware mods and flash carts, which can do the same things an emulator
|
||||
would when connected to a computer. These will require the same sort of interface software to be written in order to
|
||||
work properly--from your perspective the two won't really look any different.
|
||||
|
||||
#### My Game is an exclusive for the Super Baby Magic Dream Boy. It’s this console from the Soviet Union that-
|
||||
Unless you have a circuit schematic for the Super Baby Magic Dream Boy sitting on your desk, no.
|
||||
Obscurity is your enemy – there will likely be little to no emulator or modding information, and you’d essentially be
|
||||
working from scratch. You're welcome to try and break ground on something like this, but understand that community
|
||||
support will range from "extremely limited" to "nonexistent".
|
||||
|
||||
### How to Distribute Game Modifications
|
||||
**NEVER EVER distribute anyone else's copyrighted work UNLESS THEY EXPLICITLY GIVE YOU PERMISSION TO DO SO!!!**
|
||||
|
||||
The right way to distribute modified versions of a game's binaries is to distribute binary patches.
|
||||
|
||||
The common theme is that you can’t distribute anything that wasn't made by you. Patches are files that describe how
|
||||
your modified file differs from the original one without including the original file's content, thus avoiding the issue
|
||||
of distributing someone else’s original work.
|
||||
|
||||
Users who have a copy of the game just need to apply the patch, and those who don’t are unable to play.
|
||||
|
||||
#### Patches
|
||||
The following patch formats are commonly seen in the game modding scene.
|
||||
|
||||
##### IPS
|
||||
IPS patches are a simple list of chunks to replace in the original to generate the output. It is not possible to encode
|
||||
moving of a chunk, so they may inadvertently contain copyrighted material and should be avoided unless you know it's
|
||||
fine.
|
||||
|
||||
##### UPS, BPS, VCDIFF (xdelta), bsdiff
|
||||
Other patch formats generate the difference between two streams (delta patches) with varying complexity. This way it is
|
||||
possible to insert bytes or move chunks without including any original data. Bsdiff is highly optimized and includes
|
||||
compression, so this format is used by APBP.
|
||||
|
||||
Only a bsdiff module is integrated into AP. If the final patch requires or is based on any other patch, convert them to
|
||||
bsdiff or APBP before adding it to the AP source code as "basepatch.bsdiff4" or "basepatch.apbp".
|
||||
|
||||
##### APBP Archipelago Binary Patch
|
||||
Starting with version 4 of the APBP format, this is a ZIP file containing metadata in `archipelago.json` and additional
|
||||
files required by the game / patching process. For ROM-based games the ZIP will include a `delta.bsdiff4` which is the
|
||||
bsdiff between the original and the randomized ROM.
|
||||
|
||||
To make using APBP easy, they can be generated by inheriting from `Patch.APDeltaPatch`.
|
||||
|
||||
#### Mod files
|
||||
Games which support modding will usually just let you drag and drop the mod’s files into a folder somewhere.
|
||||
Mod files come in many forms, but the rules about not distributing other people's content remain the same.
|
||||
They can either be generic and modify the game using a seed or `slot_data` from the AP websocket, or they can be
|
||||
generated per seed.
|
||||
|
||||
If the mod is generated by AP and is installed from a ZIP file, it may be possible to include APBP metadata for easy
|
||||
integration into the Webhost by inheriting from `Patch.APContainer`.
|
||||
101
docs/sphinx/Architecture.md
Normal file
@@ -0,0 +1,101 @@
|
||||
# Archipelago Architecture
|
||||
Archipelago is split into several components. All components must operate in tandem to facilitate randomization
|
||||
and gameplay.
|
||||
|
||||
The components are:
|
||||
* [Archipelago Generator](#archipelago-generator)
|
||||
* [Archipelago Server](#archipelago-server)
|
||||
* [Archipelago Game Client](#archipelago-game-client)
|
||||
|
||||
Some games require additional components in order to facilitate gameplay or communication with Archipelago.
|
||||
The additional components vary from game to game but are typically:
|
||||
* [Retro Console Emulator](#retro-console-emulator)
|
||||
* [Emulator Communication Bridge (SNI)](#emulator-communication-bridge)
|
||||
|
||||
## Archipelago Generator
|
||||
The Archipelago Generator is the part of Archipelago which takes YAML configuration files as input and produces a ZIP
|
||||
file containing the data necessary for the Archipelago Server to service a session. The generator software is standalone
|
||||
from the server or game clients and is run outside the server context. The server may then be pointed to the resulting
|
||||
file to serve that session.
|
||||
|
||||
For more information on using the Archipelago Generator as a user, please visit the user facing MultiWorld Setup Guide
|
||||
section on [Rolling a YAML Locally](https://archipelago.gg/tutorial/Archipelago/setup/en#rolling-a-yaml-locally).
|
||||
|
||||
The Generator functions by using the classes defined in the `/worlds` folder to understand each game's items, location,
|
||||
YAML options, and logic. The "World" classes define these properties in code and are loaded by the generator to allow it
|
||||
to validate YAML options and create a multiworld with cohesive and solvable logic despite the possibility of disparate
|
||||
games being played.
|
||||
|
||||
## Archipelago Server
|
||||
The Archipelago Server facilitates gameplay for a multiworld session. A session may have any number of players.
|
||||
As Archipelago is client-server software the server is still required for sessions even if only a single player is
|
||||
present. The server takes a ZIP file or an ARCHIPELAGO file as input and serves the session using the information from
|
||||
the input to properly serve the game clients over network.
|
||||
|
||||
## Archipelago Game Client
|
||||
Archipelago game clients are currently implemented in two main ways. The first are in-process clients, which operate as
|
||||
a mod loaded within the game process. The game process will then facilitate the WebSocket communication with the
|
||||
Archipelago Server. Typically, more "modern" games will use this approach as they are typically easier to mod or are
|
||||
easier to inject with code at runtime.
|
||||
|
||||
Some examples of Archipelago games implementing the in-process model are:
|
||||
* [Risk of Rain 2](https://github.com/Ijwu/Archipelago.RiskOfRain2)
|
||||
* [Subnautica](https://github.com/Berserker66/ArchipelagoSubnauticaModSrc)
|
||||
* [Hollow Knight](https://github.com/Ijwu/Archipelago.HollowKnight)
|
||||
|
||||
The in-process model can be visualized using the following diagram:
|
||||
```{mermaid}
|
||||
flowchart LR
|
||||
APS[Archipelago Server]
|
||||
APGC[Archipelago Game Client]
|
||||
|
||||
APS <-- WebSockets --> APGC
|
||||
```
|
||||
|
||||
The second model of game client are those which operate out-of-process. The out-of-process clients are shipped with the
|
||||
Archipelago installation and live within the Archipelago codebase. They are implemented in Python using [CommonClient.py](https://github.com/ArchipelagoMW/Archipelago/blob/main/CommonClient.py)
|
||||
as a base. This client model is typically used for games in which runtime modification is difficult to impossible and for
|
||||
games which require additional components such as the emulator communication bridge. This model is also used for clients
|
||||
which communicate with the game from outside the game process to understand game state; the client then communicates
|
||||
updates to the Archipelago server based on the game state.
|
||||
|
||||
Some examples of Archipelago games implementing the out-of-process model are:
|
||||
* [Starcraft 2](https://github.com/ArchipelagoMW/Archipelago/blob/main/Starcraft2Client.py)
|
||||
* [Factorio](https://github.com/ArchipelagoMW/Archipelago/blob/main/FactorioClient.py)
|
||||
* [The Legend of Zelda: Ocarina of Time](https://github.com/ArchipelagoMW/Archipelago/blob/main/OoTClient.py)
|
||||
|
||||
The out-of-process model can be visualized using the following diagram:
|
||||
```{mermaid}
|
||||
flowchart LR
|
||||
APS[Archipelago Server]
|
||||
OOPGC[Out-of-Process Game Client]
|
||||
GP[Game Process]
|
||||
|
||||
APS <-- WebSockets --> OOPGC <--> GP
|
||||
```
|
||||
|
||||
Games which use the [SNI](https://github.com/alttpo/sni) emulator communication bridge can be connected to Archipelago using the [SNIClient](https://github.com/ArchipelagoMW/Archipelago/blob/main/SNIClient.py).
|
||||
|
||||
Games communicating using SNI may be visualized using the following diagram:
|
||||
```{mermaid}
|
||||
flowchart LR
|
||||
APS[Archipelago Server]
|
||||
SNIC[SNIClient]
|
||||
SNI[SNI]
|
||||
GP[Game Process]
|
||||
|
||||
APS <-- WebSockets --> SNIC <-- WebSockets --> SNI <--> GP
|
||||
```
|
||||
|
||||
## Retro Console Emulator
|
||||
Some game implementations require the use of an emulator in order to run the game and to communicate with SNI.
|
||||
These games are typically "retro" games which were released on 8-bit or 16-bit consoles, although newer consoles may be
|
||||
included for some game implementations.
|
||||
|
||||
All emulators currently used in Archipelago game implementations which require them are lua enabled and use a lua script
|
||||
to communicate with SNI.
|
||||
|
||||
## Emulator Communication Bridge
|
||||
All implementations of game clients for which the game is run in an emulator presently use [SuperNintendoInterface or SNI](https://github.com/alttpo/sni)
|
||||
to communicate between the emulator and the SNIClient. The emulator uses lua to communicate to SNI which communicates with
|
||||
the SNIClient which communicates with the Archipelago server.
|
||||
19
docs/sphinx/AutoWorld.md
Normal file
@@ -0,0 +1,19 @@
|
||||
World Class
|
||||
===========
|
||||
|
||||
```{eval-rst}
|
||||
.. currentmodule:: worlds.AutoWorld
|
||||
.. autoclass:: World
|
||||
:members: options, game, topology_present, all_item_and_group_names,
|
||||
item_name_to_id, location_name_to_id, item_name_groups, data_version,
|
||||
required_client_version, required_server_version, hint_blacklist,
|
||||
remote_items, remote_start_inventory, forced_auto_forfeit, hidden,
|
||||
world, player, item_id_to_name, location_id_to_name, item_names,
|
||||
location_names, web, assert_generate, generate_early, create_regions,
|
||||
create_items, set_rules, generate_basic, pre_fill, fill_hook, post_fill,
|
||||
generate_output, fill_slot_data, modify_multidata, write_spoiler_header,
|
||||
write_spoiler, write_spoiler_end, create_item, get_filler_item_name,
|
||||
collect_item, get_pre_fill_items
|
||||
:undoc-members:
|
||||
:special-members: __init__
|
||||
```
|
||||
20
docs/sphinx/Makefile
Normal file
@@ -0,0 +1,20 @@
|
||||
# Minimal makefile for Sphinx documentation
|
||||
#
|
||||
|
||||
# You can set these variables from the command line, and also
|
||||
# from the environment for the first two.
|
||||
SPHINXOPTS ?=
|
||||
SPHINXBUILD ?= sphinx-build
|
||||
SOURCEDIR = .
|
||||
BUILDDIR = _build
|
||||
|
||||
# Put it first so that "make" without argument is like "make help".
|
||||
help:
|
||||
@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
|
||||
|
||||
.PHONY: help Makefile
|
||||
|
||||
# Catch-all target: route all unknown targets to Sphinx using the new
|
||||
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
|
||||
%: Makefile
|
||||
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
|
||||
@@ -1,4 +1,8 @@
|
||||
```mermaid
|
||||
# Archipelago Network Diagram
|
||||
(Psst, scroll down and zoom in.)
|
||||
|
||||
|
||||
```{mermaid}
|
||||
flowchart LR
|
||||
%% Diagram arranged specifically so output generates no terrible crossing lines.
|
||||
%% AP Server
|
||||
@@ -69,12 +73,6 @@ flowchart LR
|
||||
end
|
||||
SNI <-- Various, depending on SNES device --> SMZ
|
||||
|
||||
%% Donkey Kong Country 3
|
||||
subgraph Donkey Kong Country 3
|
||||
DK3[SNES]
|
||||
end
|
||||
SNI <-- Various, depending on SNES device --> DK3
|
||||
|
||||
%% Native Clients or Games
|
||||
%% Games or clients which compile to native or which the client is integrated in the game.
|
||||
subgraph "Native"
|
||||
@@ -88,12 +86,10 @@ flowchart LR
|
||||
MT[Meritous]
|
||||
TW[The Witness]
|
||||
SA2B[Sonic Adventure 2: Battle]
|
||||
DS3[Dark Souls 3]
|
||||
|
||||
APCLIENTPP <--> SOE
|
||||
APCLIENTPP <--> MT
|
||||
APCLIENTPP <-- The Witness Randomizer --> TW
|
||||
APCLIENTPP <--> DS3
|
||||
APCPP <--> SM64
|
||||
APCPP <--> V6
|
||||
APCPP <--> SA2B
|
||||
@@ -1,17 +1,20 @@
|
||||
# Archipelago General Client
|
||||
# Archipelago Network Protocol
|
||||
## Archipelago Connection Handshake
|
||||
These steps should be followed in order to establish a gameplay connection with an Archipelago session.
|
||||
|
||||
1. Client establishes WebSocket connection to Archipelago server.
|
||||
2. Server accepts connection and responds with a [RoomInfo](#RoomInfo) packet.
|
||||
3. Client may send a [GetDataPackage](#GetDataPackage) packet.
|
||||
4. Server sends a [DataPackage](#DataPackage) packet in return. (If the client sent GetDataPackage.)
|
||||
5. Client sends [Connect](#Connect) packet in order to authenticate with the server.
|
||||
6. Server validates the client's packet and responds with [Connected](#Connected) or [ConnectionRefused](#ConnectionRefused).
|
||||
7. Server may send [ReceivedItems](#ReceivedItems) to the client, in the case that the client is missing items that are queued up for it.
|
||||
8. Server sends [Print](#Print) to all players to notify them of the new client connection.
|
||||
2. Server accepts connection and responds with a [RoomInfo](#roominfo) packet.
|
||||
3. Client may send a [GetDataPackage](#getdatapackage) packet.
|
||||
4. Server sends a [DataPackage](#datapackage) packet in return. (If the client sent GetDataPackage.)
|
||||
5. Client sends [Connect](#connect) packet in order to authenticate with the server.
|
||||
6. Server validates the client's packet and responds with [Connected](#connected) or
|
||||
[ConnectionRefused](#connectionrefused).
|
||||
7. Server may send [ReceivedItems](#receiveditems) to the client, in the case that the client is missing items that
|
||||
are queued up for it.
|
||||
8. Server sends [Print](#print) to all players to notify them of the new client connection.
|
||||
|
||||
In the case that the client does not authenticate properly and receives a [ConnectionRefused](#ConnectionRefused) then the server will maintain the connection and allow for follow-up [Connect](#Connect) packet.
|
||||
In the case that the client does not authenticate properly and receives a [ConnectionRefused](#connectionrefused) then
|
||||
the server will maintain the connection and allow for follow-up [Connect](#connect) packet.
|
||||
|
||||
There are also a number of community-supported libraries available that implement this network protocol to make integrating with Archipelago easier.
|
||||
|
||||
@@ -27,18 +30,26 @@ There are also a number of community-supported libraries available that implemen
|
||||
| Haxe | [hxArchipelago](https://lib.haxe.org/p/hxArchipelago) | |
|
||||
|
||||
## Synchronizing Items
|
||||
When the client receives a [ReceivedItems](#ReceivedItems) packet, if the `index` argument does not match the next index that the client expects then it is expected that the client will re-sync items with the server. This can be accomplished by sending the server a [Sync](#Sync) packet and then a [LocationChecks](#LocationChecks) packet.
|
||||
When the client receives a [ReceivedItems](#receiveditems) packet, if the `index` argument does not match the next index
|
||||
that the client expects then it is expected that the client will re-sync items with the server. This can be accomplished
|
||||
by sending the server a [Sync](#sync) packet and then a [LocationChecks](#locationchecks) packet.
|
||||
|
||||
Even if the client detects a desync, it can still accept the items provided in this packet to prevent gameplay interruption.
|
||||
Even if the client detects a desync, it can still accept the items provided in this packet to prevent gameplay
|
||||
interruption.
|
||||
|
||||
When the client receives a [ReceivedItems](#ReceivedItems) packet and the `index` arg is `0` (zero) then the client should accept the provided `items` list as its full inventory. (Abandon previous inventory.)
|
||||
When the client receives a [ReceivedItems](#receiveditems) packet and the `index` arg is `0` (zero) then the client
|
||||
should accept the provided `items` list as its full inventory. (Abandon previous inventory.)
|
||||
|
||||
# Archipelago Protocol Packets
|
||||
Packets are sent between the multiworld server and client in order to sync information between them. Below is a directory of each packet.
|
||||
## Archipelago Protocol Packets
|
||||
Packets are sent between the multiworld server and client in order to sync information between them.
|
||||
Below is a directory of each packet.
|
||||
|
||||
Packets are simple JSON lists in which any number of ordered network commands can be sent, which are objects. Each command has a "cmd" key, indicating its purpose. All packet argument types documented here refer to JSON types, unless otherwise specified.
|
||||
Packets are simple JSON lists in which any number of ordered network commands can be sent, which are objects.
|
||||
Each command has a "cmd" key, indicating its purpose. All packet argument types documented here refer to JSON types,
|
||||
unless otherwise specified.
|
||||
|
||||
An object can contain the "class" key, which will tell the content data type, such as "Version" in the following example.
|
||||
An object can contain the "class" key, which will tell the content data type, such as "Version" in the following
|
||||
example.
|
||||
|
||||
Example:
|
||||
```javascript
|
||||
@@ -46,40 +57,41 @@ Example:
|
||||
```
|
||||
|
||||
## (Server -> Client)
|
||||
These packets are are sent from the multiworld server to the client. They are not messages which the server accepts.
|
||||
* [RoomInfo](#RoomInfo)
|
||||
* [ConnectionRefused](#ConnectionRefused)
|
||||
* [Connected](#Connected)
|
||||
* [ReceivedItems](#ReceivedItems)
|
||||
* [LocationInfo](#LocationInfo)
|
||||
* [RoomUpdate](#RoomUpdate)
|
||||
* [Print](#Print)
|
||||
* [PrintJSON](#PrintJSON)
|
||||
* [DataPackage](#DataPackage)
|
||||
* [Bounced](#Bounced)
|
||||
* [InvalidPacket](#InvalidPacket)
|
||||
* [Retrieved](#Retrieved)
|
||||
* [SetReply](#SetReply)
|
||||
These packets are sent from the multiworld server to the client. They are not messages which the server accepts.
|
||||
* [RoomInfo](#roominfo)
|
||||
* [ConnectionRefused](#connectionrefused)
|
||||
* [Connected](#connected)
|
||||
* [ReceivedItems](#receiveditems)
|
||||
* [LocationInfo](#locationinfo)
|
||||
* [RoomUpdate](#roomupdate)
|
||||
* [Print](#print)
|
||||
* [PrintJSON](#printjson)
|
||||
* [DataPackage](#datapackage)
|
||||
* [Bounced](#bounced)
|
||||
* [InvalidPacket](#invalidpacket)
|
||||
* [Retrieved](#retrieved)
|
||||
* [SetReply](#setreply)
|
||||
|
||||
### RoomInfo
|
||||
Sent to clients when they connect to an Archipelago server.
|
||||
#### Arguments
|
||||
| Name | Type | Notes |
|
||||
| ---- | ---- | ----- |
|
||||
| version | [NetworkVersion](#NetworkVersion) | Object denoting the version of Archipelago which the server is running. |
|
||||
| version | [NetworkVersion](#networkversion) | Object denoting the version of Archipelago which the server is running. |
|
||||
| tags | list\[str\] | Denotes special features or capabilities that the sender is capable of. Example: `WebHost` |
|
||||
| password | bool | Denoted whether a password is required to join this room.|
|
||||
| permissions | dict\[str, [Permission](#Permission)\[int\]\] | Mapping of permission name to [Permission](#Permission), keys are: "forfeit", "collect" and "remaining". |
|
||||
| permissions | dict\[str, [Permission](#permission)\[int\]\] | Mapping of permission name to [Permission](#permission), keys are: "forfeit", "collect" and "remaining". |
|
||||
| hint_cost | int | The amount of points it costs to receive a hint from the server. |
|
||||
| location_check_points | int | The amount of hint points you receive per item/location check completed. ||
|
||||
| games | list\[str\] | List of games present in this multiworld. |
|
||||
| datapackage_version | int | Sum of individual games' datapackage version. Deprecated. Use `datapackage_versions` instead. |
|
||||
| datapackage_versions | dict\[str, int\] | Data versions of the individual games' data packages the server will send. Used to decide which games' caches are outdated. See [Data Package Contents](#Data-Package-Contents). |
|
||||
| datapackage_versions | dict\[str, int\] | Data versions of the individual games' data packages the server will send. Used to decide which games' caches are outdated. See [Data Package Contents](#data-package-contents). |
|
||||
| seed_name | str | uniquely identifying name of this generation |
|
||||
| time | float | Unix time stamp of "now". Send for time synchronization if wanted for things like the DeathLink Bounce. |
|
||||
|
||||
#### forfeit
|
||||
Dictates what is allowed when it comes to a player forfeiting their run. A forfeit is an action which distributes the rest of the items in a player's run to those other players awaiting them.
|
||||
Dictates what is allowed when it comes to a player forfeiting their run. A forfeit is an action which distributes the
|
||||
rest of the items in a player's run to those other players awaiting them.
|
||||
|
||||
* `auto`: Distributes a player's items to other players when they complete their goal.
|
||||
* `enabled`: Denotes that players may forfeit at any time in the game.
|
||||
@@ -88,7 +100,8 @@ Dictates what is allowed when it comes to a player forfeiting their run. A forfe
|
||||
* `goal`: Allows for manual use of forfeit command once a player completes their goal. (Disabled until goal completion)
|
||||
|
||||
#### collect
|
||||
Dictates what is allowed when it comes to a player collecting their run. A collect is an action which sends the rest of the items in a player's run.
|
||||
Dictates what is allowed when it comes to a player collecting their run. A collect is an action which sends the rest of
|
||||
the items in a player's run.
|
||||
|
||||
* `auto`: Automatically when they complete their goal.
|
||||
* `enabled`: Denotes that players may !collect at any time in the game.
|
||||
@@ -122,13 +135,13 @@ Sent to clients when the connection handshake is successfully completed.
|
||||
#### Arguments
|
||||
| Name | Type | Notes |
|
||||
| ---- | ---- | ----- |
|
||||
| team | int | Your team number. See [NetworkPlayer](#NetworkPlayer) for more info on team number. |
|
||||
| slot | int | Your slot number on your team. See [NetworkPlayer](#NetworkPlayer) for more info on the slot number. |
|
||||
| players | list\[[NetworkPlayer](#NetworkPlayer)\] | List denoting other players in the multiworld, whether connected or not. |
|
||||
| team | int | Your team number. See [NetworkPlayer](#networkplayer) for more info on team number. |
|
||||
| slot | int | Your slot number on your team. See [NetworkPlayer](#networkplayer) for more info on the slot number. |
|
||||
| players | list\[[NetworkPlayer](#networkplayer)\] | List denoting other players in the multiworld, whether connected or not. |
|
||||
| missing_locations | list\[int\] | Contains ids of remaining locations that need to be checked. Useful for trackers, among other things. |
|
||||
| checked_locations | list\[int\] | Contains ids of all locations that have been checked. Useful for trackers, among other things. Location ids are in the range of ± 2<sup>53</sup>-1. |
|
||||
| slot_data | dict | Contains a json object for slot related data, differs per game. Empty if not required. |
|
||||
| slot_info | dict\[int, [NetworkSlot](#NetworkSlot)\] | maps each slot to a [NetworkSlot](#NetworkSlot) information |
|
||||
| slot_info | dict\[int, [NetworkSlot](#networkslot)\] | maps each slot to a [NetworkSlot](#networkslot) information |
|
||||
|
||||
### ReceivedItems
|
||||
Sent to clients when they receive an item.
|
||||
@@ -136,25 +149,25 @@ Sent to clients when they receive an item.
|
||||
| Name | Type | Notes |
|
||||
| ---- | ---- | ----- |
|
||||
| index | int | The next empty slot in the list of items for the receiving client. |
|
||||
| items | list\[[NetworkItem](#NetworkItem)\] | The items which the client is receiving. |
|
||||
| items | list\[[NetworkItem](#networkitem)\] | The items which the client is receiving. |
|
||||
|
||||
### LocationInfo
|
||||
Sent to clients to acknowledge a received [LocationScouts](#LocationScouts) packet and responds with the item in the location(s) being scouted.
|
||||
Sent to clients to acknowledge a received [LocationScouts](#locationscouts) packet and responds with the item in the location(s) being scouted.
|
||||
#### Arguments
|
||||
| Name | Type | Notes |
|
||||
| ---- | ---- | ----- |
|
||||
| locations | list\[[NetworkItem](#NetworkItem)\] | Contains list of item(s) in the location(s) scouted. |
|
||||
| locations | list\[[NetworkItem](#networkitem)\] | Contains list of item(s) in the location(s) scouted. |
|
||||
|
||||
### RoomUpdate
|
||||
Sent when there is a need to update information about the present game session. Generally useful for async games.
|
||||
Once authenticated (received Connected), this may also contain data from Connected.
|
||||
#### Arguments
|
||||
The arguments for RoomUpdate are identical to [RoomInfo](#RoomInfo) barring:
|
||||
The arguments for RoomUpdate are identical to [RoomInfo](#roominfo) barring:
|
||||
|
||||
| Name | Type | Notes |
|
||||
| ---- | ---- | ----- |
|
||||
| hint_points | int | New argument. The client's current hint points. |
|
||||
| players | list\[[NetworkPlayer](#NetworkPlayer)\] | Send in the event of an alias rename. Always sends all players, whether connected or not. |
|
||||
| players | list\[[NetworkPlayer](#networkplayer)\] | Send in the event of an alias rename. Always sends all players, whether connected or not. |
|
||||
| checked_locations | list\[int\] | May be a partial update, containing new locations that were checked, especially from a coop partner in the same slot. |
|
||||
| missing_locations | list\[int\] | Should never be sent as an update, if needed is the inverse of checked_locations. |
|
||||
|
||||
@@ -169,14 +182,15 @@ Sent to clients purely to display a message to the player.
|
||||
| text | str | Message to display to player. |
|
||||
|
||||
### PrintJSON
|
||||
Sent to clients purely to display a message to the player. This packet differs from [Print](#Print) in that the data being sent with this packet allows for more configurable or specific messaging.
|
||||
Sent to clients purely to display a message to the player. This packet differs from [Print](#print) in that the data
|
||||
being sent with this packet allows for more configurable or specific messaging.
|
||||
#### Arguments
|
||||
| Name | Type | Notes |
|
||||
| ---- | ---- | ----- |
|
||||
| data | list\[[JSONMessagePart](#JSONMessagePart)\] | Type of this part of the message. |
|
||||
| type | str | May be present to indicate the [PrintJsonType](#PrintJsonType) of this message. |
|
||||
| receiving | int | Is present if type is Hint or ItemSend and marks the destination player's ID. |
|
||||
| item | [NetworkItem](#NetworkItem) | Is present if type is Hint or ItemSend and marks the source player id, location id, item id and item flags. |
|
||||
| item | [NetworkItem](#networkitem) | Is present if type is Hint or ItemSend and marks the source player id, location id, item id and item flags. |
|
||||
| found | bool | Is present if type is Hint, denotes whether the location hinted for was checked. |
|
||||
| countdown | int | Is present if type is `Countdown`, denotes the amount of seconds remaining on the countdown. |
|
||||
|
||||
@@ -191,35 +205,37 @@ Currently defined types are:
|
||||
| Countdown | The message contains information about the current server Countdown. |
|
||||
|
||||
### DataPackage
|
||||
Sent to clients to provide what is known as a 'data package' which contains information to enable a client to most easily communicate with the Archipelago server. Contents include things like location id to name mappings, among others; see [Data Package Contents](#Data-Package-Contents) for more info.
|
||||
Sent to clients to provide what is known as a 'data package' which contains information to enable a client to most
|
||||
easily communicate with the Archipelago server. Contents include things like location id to name mappings,
|
||||
among others; see [Data Package Contents](#data-package-contents) for more info.
|
||||
|
||||
#### Arguments
|
||||
| Name | Type | Notes |
|
||||
| ---- | ---- | ----- |
|
||||
| data | [DataPackageObject](#Data-Package-Contents) | The data package as a JSON object. |
|
||||
| data | [DataPackageObject](#data-package-contents) | The data package as a JSON object. |
|
||||
|
||||
### Bounced
|
||||
Sent to clients after a client requested this message be sent to them, more info in the [Bounce](#Bounce) package.
|
||||
Sent to clients after a client requested this message be sent to them, more info in the [Bounce](#bounce) package.
|
||||
|
||||
#### Arguments
|
||||
| Name | Type | Notes |
|
||||
| ---- | ---- | ----- |
|
||||
| games | list\[str\] | Optional. Game names this message is targeting |
|
||||
| slots | list\[int\] | Optional. Player slot IDs that this message is targeting |
|
||||
| tags | list\[str\] | Optional. Client [Tags](#Tags) this message is targeting |
|
||||
| data | dict | The data in the [Bounce](#Bounce) package copied |
|
||||
| tags | list\[str\] | Optional. Client [Tags](#tags) this message is targeting |
|
||||
| data | dict | The data in the [Bounce](#bounce) package copied |
|
||||
|
||||
### InvalidPacket
|
||||
Sent to clients if the server caught a problem with a packet. This only occurs for errors that are explicitly checked for.
|
||||
|
||||
#### Arguments
|
||||
| Name | Type | Notes |
|
||||
| ---- | ---- | ----- |
|
||||
| type | str | The [PacketProblemType](#PacketProblemType) that was detected in the packet. |
|
||||
| Name | Type | Notes |
|
||||
|--------------|---------------|-------------------------------------------------------------------------------------------|
|
||||
| type | str | The [PacketProblemType](#packetproblemtype) that was detected in the packet. |
|
||||
| original_cmd | Optional[str] | The `cmd` argument of the faulty packet, will be `None` if the `cmd` failed to be parsed. |
|
||||
| text | str | A descriptive message of the problem at hand. |
|
||||
| text | str | A descriptive message of the problem at hand. |
|
||||
|
||||
##### PacketProblemType
|
||||
#### PacketProblemType
|
||||
`PacketProblemType` indicates the type of problem that was detected in the faulty packet, the known problem types are below but others may be added in the future.
|
||||
|
||||
| Type | Notes |
|
||||
@@ -228,16 +244,19 @@ Sent to clients if the server caught a problem with a packet. This only occurs f
|
||||
| arguments | Arguments of the faulty packet which were not correct. |
|
||||
|
||||
### Retrieved
|
||||
Sent to clients as a response the a [Get](#Get) package.
|
||||
Sent to clients as a response the a [Get](#get) package
|
||||
#### Arguments
|
||||
| Name | Type | Notes |
|
||||
| ---- | ---- | ----- |
|
||||
| keys | dict\[str\, any] | A key-value collection containing all the values for the keys requested in the [Get](#Get) package. |
|
||||
| keys | dict\[str\, any] | A key-value collection containing all the values for the keys requested in the [Get](#get) package. |
|
||||
|
||||
Additional arguments added to the [Get](#Get) package that triggered this [Retrieved](#Retrieved) will also be passed along.
|
||||
Additional arguments added to the [Get](#get) package that triggered this [Retrieved](#retrieved) will also be passed
|
||||
along.
|
||||
|
||||
### SetReply
|
||||
Sent to clients in response to a [Set](#Set) package if want_reply was set to true, or if the client has registered to receive updates for a certain key using the [SetNotify](#SetNotify) package. SetReply packages are sent even if a [Set](#Set) package did not alter the value for the key.
|
||||
Sent to clients in response to a [Set](#set) package if want_reply was set to true, or if the client has registered to
|
||||
receive updates for a certain key using the [SetNotify](#setnotify) package. SetReply packages are sent even if a
|
||||
[Set](#set) package did not alter the value for the key.
|
||||
#### Arguments
|
||||
| Name | Type | Notes |
|
||||
| ---- | ---- | ----- |
|
||||
@@ -245,22 +264,23 @@ Sent to clients in response to a [Set](#Set) package if want_reply was set to tr
|
||||
| value | any | The new value for the key. |
|
||||
| original_value | any | The value the key had before it was updated. |
|
||||
|
||||
Additional arguments added to the [Set](#Set) package that triggered this [SetReply](#SetReply) will also be passed along.
|
||||
Additional arguments added to the [Set](#set) package that triggered this [SetReply](#setreply) will also be passed
|
||||
along.
|
||||
|
||||
## (Client -> Server)
|
||||
These packets are sent purely from client to server. They are not accepted by clients.
|
||||
|
||||
* [Connect](#Connect)
|
||||
* [Sync](#Sync)
|
||||
* [LocationChecks](#LocationChecks)
|
||||
* [LocationScouts](#LocationScouts)
|
||||
* [StatusUpdate](#StatusUpdate)
|
||||
* [Say](#Say)
|
||||
* [GetDataPackage](#GetDataPackage)
|
||||
* [Bounce](#Bounce)
|
||||
* [Get](#Get)
|
||||
* [Set](#Set)
|
||||
* [SetNotify](#SetNotify)
|
||||
* [Connect](#connect)
|
||||
* [Sync](#sync)
|
||||
* [LocationChecks](#locationchecks)
|
||||
* [LocationScouts](#locationscouts)
|
||||
* [StatusUpdate](#statusupdate)
|
||||
* [Say](#say)
|
||||
* [GetDataPackage](#getdatapackage)
|
||||
* [Bounce](#bounce)
|
||||
* [Get](#get)
|
||||
* [Set](#set)
|
||||
* [SetNotify](#setnotify)
|
||||
|
||||
### Connect
|
||||
Sent by the client to initiate a connection to an Archipelago game session.
|
||||
@@ -272,9 +292,9 @@ Sent by the client to initiate a connection to an Archipelago game session.
|
||||
| game | str | The name of the game the client is playing. Example: `A Link to the Past` |
|
||||
| name | str | The player name for this client. |
|
||||
| uuid | str | Unique identifier for player client. |
|
||||
| version | [NetworkVersion](#NetworkVersion) | An object representing the Archipelago version this client supports. |
|
||||
| version | [NetworkVersion](#networkversion) | An object representing the Archipelago version this client supports. |
|
||||
| items_handling | int | Flags configuring which items should be sent by the server. Read below for individual flags. |
|
||||
| tags | list\[str\] | Denotes special features or capabilities that the sender is capable of. [Tags](#Tags) |
|
||||
| tags | list\[str\] | Denotes special features or capabilities that the sender is capable of. [Tags](#tags) |
|
||||
|
||||
#### items_handling flags
|
||||
| Value | Meaning |
|
||||
@@ -286,7 +306,8 @@ Sent by the client to initiate a connection to an Archipelago game session.
|
||||
| null | Null or undefined loads settings from world definition for backwards compatibility. This is deprecated. |
|
||||
|
||||
#### Authentication
|
||||
Many, if not all, other packets require a successfully authenticated client. This is described in more detail in [Archipelago Connection Handshake](#Archipelago-Connection-Handshake).
|
||||
Many, if not all, other packets require a successfully authenticated client. This is described in more detail in
|
||||
[Archipelago Connection Handshake](#archipelago-connection-handshake).
|
||||
|
||||
### ConnectUpdate
|
||||
Update arguments from the Connect package, currently only updating tags and items_handling is supported.
|
||||
@@ -295,15 +316,16 @@ Update arguments from the Connect package, currently only updating tags and item
|
||||
| Name | Type | Notes |
|
||||
| ---- | ---- | ----- |
|
||||
| items_handling | int | Flags configuring which items should be sent by the server. |
|
||||
| tags | list\[str\] | Denotes special features or capabilities that the sender is capable of. [Tags](#Tags) |
|
||||
| tags | list\[str\] | Denotes special features or capabilities that the sender is capable of. [Tags](#tags) |
|
||||
|
||||
### Sync
|
||||
Sent to server to request a [ReceivedItems](#ReceivedItems) packet to synchronize items.
|
||||
Sent to server to request a [ReceivedItems](#receiveditems) packet to synchronize items.
|
||||
#### Arguments
|
||||
No arguments necessary.
|
||||
|
||||
### LocationChecks
|
||||
Sent to server to inform it of locations that the client has checked. Used to inform the server of new checks that are made, as well as to sync state.
|
||||
Sent to server to inform it of locations that the client has checked. Used to inform the server of new checks that are
|
||||
made, as well as to sync state.
|
||||
|
||||
#### Arguments
|
||||
| Name | Type | Notes |
|
||||
@@ -311,13 +333,15 @@ Sent to server to inform it of locations that the client has checked. Used to in
|
||||
| locations | list\[int\] | The ids of the locations checked by the client. May contain any number of checks, even ones sent before; duplicates do not cause issues with the Archipelago server. |
|
||||
|
||||
### LocationScouts
|
||||
Sent to the server to inform it of locations the client has seen, but not checked. Useful in cases in which the item may appear in the game world, such as 'ledge items' in A Link to the Past. The server will always respond with a [LocationInfo](#LocationInfo) packet with the items located in the scouted location.
|
||||
Sent to the server to inform it of locations the client has seen, but not checked. Useful in cases in which the item may
|
||||
appear in the game world, such as 'ledge items' in A Link to the Past. The server will always respond with a
|
||||
[LocationInfo](#locationinfo) packet with the items located in the scouted location.
|
||||
|
||||
#### Arguments
|
||||
| Name | Type | Notes |
|
||||
| ---- | ---- | ----- |
|
||||
| locations | list\[int\] | The ids of the locations seen by the client. May contain any number of locations, even ones sent before; duplicates do not cause issues with the Archipelago server. |
|
||||
| create_as_hint | int | If non-zero, the scouted locations get created and broadcasted as a player-visible hint. <br/>If 2 only new hints are broadcast, however this does not remove them from the LocationInfo reply. |
|
||||
| create_as_hint | int | If non-zero, the scouted locations get created and broadcast as a player-visible hint. <br/>If 2 only new hints are broadcast, however this does not remove them from the LocationInfo reply. |
|
||||
|
||||
### StatusUpdate
|
||||
Sent to the server to update on the sender's status. Examples include readiness or goal completion. (Example: defeated Ganon in A Link to the Past)
|
||||
@@ -325,7 +349,7 @@ Sent to the server to update on the sender's status. Examples include readiness
|
||||
#### Arguments
|
||||
| Name | Type | Notes |
|
||||
| ---- | ---- | ----- |
|
||||
| status | ClientStatus\[int\] | One of [Client States](#Client-States). Send as int. Follow the link for more information. |
|
||||
| status | ClientStatus\[int\] | One of [Client States](#client-states). Send as int. Follow the link for more information. |
|
||||
|
||||
### Say
|
||||
Basic chat command which sends text to the server to be distributed to other clients.
|
||||
@@ -339,8 +363,8 @@ Basic chat command which sends text to the server to be distributed to other cli
|
||||
Requests the data package from the server. Does not require client authentication.
|
||||
|
||||
#### Arguments
|
||||
| Name | Type | Notes |
|
||||
|-------| ----- |---------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Name | Type | Notes |
|
||||
|-------| ----- | ---- |
|
||||
| games | list\[str\] | Optional. If specified, will only send back the specified data. Such as, \["Factorio"\] -> Datapackage with only Factorio data. |
|
||||
|
||||
### Bounce
|
||||
@@ -356,29 +380,36 @@ the server will forward the message to all those targets to which any one requir
|
||||
| data | dict | Any data you want to send |
|
||||
|
||||
### Get
|
||||
Used to request a single or multiple values from the server's data storage, see the [Set](#Set) package for how to write values to the data storage. A Get package will be answered with a [Retrieved](#Retrieved) package.
|
||||
Used to request a single or multiple values from the server's data storage, see the [Set](#set) package for how to write
|
||||
values to the data storage. A Get package will be answered with a [Retrieved](#retrieved) package.
|
||||
#### Arguments
|
||||
| Name | Type | Notes |
|
||||
| ------ | ----- | ------ |
|
||||
| keys | list\[str\] | Keys to retrieve the values for. |
|
||||
|
||||
Additional arguments sent in this package will also be added to the [Retrieved](#Retrieved) package it triggers.
|
||||
Additional arguments sent in this package will also be added to the [Retrieved](#retrieved) package it triggers.
|
||||
|
||||
### Set
|
||||
Used to write data to the server's data storage, that data can then be shared across worlds or just saved for later. Values for keys in the data storage can be retrieved with a [Get](#Get) package, or monitored with a [SetNotify](#SetNotify) package.
|
||||
Used to write data to the server's data storage, that data can then be shared across worlds or just saved for later.
|
||||
Values for keys in the data storage can be retrieved with a [Get](#get) package, or monitored with a
|
||||
[SetNotify](#setnotify) package.
|
||||
#### Arguments
|
||||
| Name | Type | Notes |
|
||||
| ------ | ----- | ------ |
|
||||
| key | str | The key to manipulate. |
|
||||
| default | any | The default value to use in case the key has no value on the server. |
|
||||
| want_reply | bool | If set, the server will send a [SetReply](#SetReply) response back to the client. |
|
||||
| operations | list\[[DataStorageOperation](#DataStorageOperation)\] | Operations to apply to the value, multiple operations can be present and they will be executed in order of appearance. |
|
||||
| want_reply | bool | If set, the server will send a [SetReply](#setreply) response back to the client. |
|
||||
| operations | list\[[DataStorageOperation](#datastorageoperation)\] | Operations to apply to the value, multiple operations can be present and they will be executed in order of appearance. |
|
||||
|
||||
Additional arguments sent in this package will also be added to the [SetReply](#SetReply) package it triggers.
|
||||
Additional arguments sent in this package will also be added to the [SetReply](#setreply) package it triggers.
|
||||
|
||||
#### DataStorageOperation
|
||||
A DataStorageOperation manipulates or alters the value of a key in the data storage. If the operation transforms the value from one state to another then the current value of the key is used as the starting point otherwise the [Set](#Set)'s package `default` is used if the key does not exist on the server already.
|
||||
DataStorageOperations consist of an object containing both the operation to be applied, provided in the form of a string, as well as the value to be used for that operation, Example:
|
||||
A DataStorageOperation manipulates or alters the value of a key in the data storage. If the operation transforms the
|
||||
value from one state to another then the current value of the key is used as the starting point otherwise the
|
||||
[Set](#set)'s package `default` is used if the key does not exist on the server already.
|
||||
|
||||
DataStorageOperations consist of an object containing both the operation to be applied, provided in the form of a
|
||||
string, as well as the value to be used for that operation, Example:
|
||||
```json
|
||||
{"operation": "add", "value": 12}
|
||||
```
|
||||
@@ -387,7 +418,7 @@ The following operations can be applied to a datastorage key
|
||||
| Operation | Effect |
|
||||
| ------ | ----- |
|
||||
| replace | Sets the current value of the key to `value`. |
|
||||
| default | If the key has no value yet, sets the current value of the key to `default` of the [Set](#Set)'s package (`value` is ignored). |
|
||||
| default | If the key has no value yet, sets the current value of the key to `default` of the [Set](#set)'s package (`value` is ignored). |
|
||||
| add | Adds `value` to the current value of the key, if both the current value and `value` are arrays then `value` will be appended to the current value. |
|
||||
| mul | Multiplies the current value of the key by `value`. |
|
||||
| pow | Multiplies the current value of the key to the power of `value`. |
|
||||
@@ -401,28 +432,35 @@ The following operations can be applied to a datastorage key
|
||||
| right_shift | Applies a bitwise right-shift to the current value of the key by `value`. |
|
||||
|
||||
### SetNotify
|
||||
Used to register your current session for receiving all [SetReply](#SetReply) packages of certain keys to allow your client to keep track of changes.
|
||||
Used to register your current session for receiving all [SetReply](#setreply) packages of certain keys to allow your client to keep track of changes.
|
||||
#### Arguments
|
||||
| Name | Type | Notes |
|
||||
| ------ | ----- | ------ |
|
||||
| keys | list\[str\] | Keys to receive all [SetReply](#SetReply) packages for. |
|
||||
| keys | list\[str\] | Keys to receive all [SetReply](#setreply) packages for. |
|
||||
|
||||
## Appendix
|
||||
|
||||
### Coop
|
||||
Coop in Archipelago is automatically facilitated by the server, however some of the default behaviour may not be what you desire.
|
||||
Coop in Archipelago is automatically facilitated by the server, however some default behaviour may not be what you
|
||||
desire.
|
||||
|
||||
If the game in question is a remote-items game (attribute on AutoWorld), then all items will always be sent and received.
|
||||
If the game in question is not a remote-items game, then any items that are placed within the same world will not be send by the server.
|
||||
If the game in question is not a remote-items game, then any items that are placed within the same world will not be
|
||||
sent by the server.
|
||||
|
||||
To manually react to others in the same player slot doing checks, listen to [RoomUpdate](#RoomUpdate) -> checked_locations.
|
||||
To manually react to others in the same player slot doing checks, listen to [RoomUpdate](#roomupdate) ->
|
||||
checked_locations.
|
||||
|
||||
### NetworkPlayer
|
||||
A list of objects. Each object denotes one player. Each object has four fields about the player, in this order: `team`, `slot`, `alias`, and `name`. `team` and `slot` are ints, `alias` and `name` are strs.
|
||||
A list of objects. Each object denotes one player. Each object has four fields about the player, in this order: `team`,
|
||||
`slot`, `alias`, and `name`. `team` and `slot` are ints, `alias` and `name` are strings.
|
||||
|
||||
Each player belongs to a `team` and has a `slot`. Team numbers start at `0`. Slot numbers are unique per team and start at `1`. Slot number `0` refers to the Archipelago server; this may appear in instances where the server grants the player an item.
|
||||
Each player belongs to a `team` and has a `slot`. Team numbers start at `0`. Slot numbers are unique per team and start
|
||||
at `1`. Slot number `0` refers to the Archipelago server; this may appear in instances where the server grants the
|
||||
player an item.
|
||||
|
||||
`alias` represents the player's name in current time. `name` is the original name used when the session was generated. This is typically distinct in games which require baking names into ROMs or for async games.
|
||||
`alias` represents the player's name in current time. `name` is the original name used when the session was generated.
|
||||
This is typically distinct in games which require baking names into ROMs or for async games.
|
||||
|
||||
```python
|
||||
from typing import NamedTuple
|
||||
@@ -465,7 +503,8 @@ In JSON this may look like:
|
||||
|
||||
`location` is the location id of the item inside the world. Location ids are in the range of ± 2<sup>53</sup>-1.
|
||||
|
||||
`player` is the player slot of the world the item is located in, except when inside an [LocationInfo](#LocationInfo) Packet then it will be the slot of the player to receive the item
|
||||
`player` is the player slot of the world the item is located in, except when inside an [LocationInfo](#locationinfo)
|
||||
Packet then it will be the slot of the player to receive the item.
|
||||
|
||||
`flags` are bit flags:
|
||||
| Flag | Meaning |
|
||||
@@ -476,7 +515,8 @@ In JSON this may look like:
|
||||
| 0b100 | If set, indicates the item is a trap |
|
||||
|
||||
### JSONMessagePart
|
||||
Message nodes sent along with [PrintJSON](#PrintJSON) packet to be reconstructed into a legible message. The nodes are intended to be read in the order they are listed in the packet.
|
||||
Message nodes sent along with [PrintJSON](#printjson) packet to be reconstructed into a legible message.
|
||||
The nodes are intended to be read in the order they are listed in the packet.
|
||||
|
||||
```python
|
||||
from typing import TypedDict, Optional
|
||||
@@ -488,7 +528,10 @@ class JSONMessagePart(TypedDict):
|
||||
player: Optional[int] # only available if type is either item or location
|
||||
```
|
||||
|
||||
`type` is used to denote the intent of the message part. This can be used to indicate special information which may be rendered differently depending on client. How these types are displayed in Archipelago's ALttP client is not the end-all be-all. Other clients may choose to interpret and display these messages differently.
|
||||
`type` is used to denote the intent of the message part. This can be used to indicate special information which may be
|
||||
rendered differently depending on client. How these types are displayed in Archipelago's ALttP client is not the end-all
|
||||
be-all. Other clients may choose to interpret and display these messages differently.
|
||||
|
||||
Possible values for `type` include:
|
||||
|
||||
| Name | Notes |
|
||||
@@ -504,7 +547,10 @@ Possible values for `type` include:
|
||||
| color | Regular text that should be colored. Only `type` that will contain `color` data. |
|
||||
|
||||
|
||||
`color` is used to denote a console color to display the message part with and is only send if the `type` is `color`. This is limited to console colors due to backwards compatibility needs with games such as ALttP. Although background colors as well as foreground colors are listed, only one may be applied to a [JSONMessagePart](#JSONMessagePart) at a time.
|
||||
`color` is used to denote a console color to display the message part with and is only send if the `type` is `color`.
|
||||
This is limited to console colors due to backwards compatibility needs with games such as ALttP.
|
||||
Although background colors as well as foreground colors are listed, only one may be applied to a
|
||||
[JSONMessagePart](#jsonmessagepart) at a time.
|
||||
|
||||
Color options:
|
||||
* bold
|
||||
@@ -528,10 +574,11 @@ Color options:
|
||||
|
||||
`text` is the content of the message part to be displayed.
|
||||
`player` marks owning player id for location/item,
|
||||
`flags` contains the [NetworkItem](#NetworkItem) flags that belong to the item
|
||||
`flags` contains the [NetworkItem](#networkitem) flags that belong to the item
|
||||
|
||||
### Client States
|
||||
An enumeration containing the possible client states that may be used to inform the server in [StatusUpdate](#StatusUpdate).
|
||||
An enumeration containing the possible client states that may be used to inform the server in
|
||||
[StatusUpdate](#statusupdate).
|
||||
|
||||
```python
|
||||
import enum
|
||||
@@ -543,7 +590,8 @@ class ClientStatus(enum.IntEnum):
|
||||
```
|
||||
|
||||
### NetworkVersion
|
||||
An object representing software versioning. Used in the [Connect](#Connect) packet to allow the client to inform the server of the Archipelago version it supports.
|
||||
An object representing software versioning. Used in the [Connect](#connect) packet to allow the client to inform the
|
||||
server of the Archipelago version it supports.
|
||||
```python
|
||||
from typing import NamedTuple
|
||||
class Version(NamedTuple):
|
||||
@@ -589,9 +637,14 @@ class Permission(enum.IntEnum):
|
||||
```
|
||||
|
||||
### Data Package Contents
|
||||
A data package is a JSON object which may contain arbitrary metadata to enable a client to interact with the Archipelago server most easily. Currently, this package is used to send ID to name mappings so that clients need not maintain their own mappings.
|
||||
A data package is a JSON object which may contain arbitrary metadata to enable a client to interact with the Archipelago
|
||||
server most easily. Currently, this package is used to send ID to name mappings so that clients need not maintain their
|
||||
own mappings.
|
||||
|
||||
We encourage clients to cache the data package they receive on disk, or otherwise not tied to a session. You will know when your cache is outdated if the [RoomInfo](#RoomInfo) packet or the datapackage itself denote a different version. A special case is datapackage version 0, where it is expected the package is custom and should not be cached.
|
||||
We encourage clients to cache the data package they receive on disk, or otherwise not tied to a session.
|
||||
You will know when your cache is outdated if the [RoomInfo](#roominfo) packet or the datapackage itself denote a
|
||||
different version. A special case is datapackage version 0, where it is expected the package is custom and should not be
|
||||
cached.
|
||||
|
||||
Note:
|
||||
* Any ID is unique to its type across AP: Item 56 only exists once and Location 56 only exists once.
|
||||
@@ -619,7 +672,7 @@ Tags are represented as a list of strings, the common Client tags follow:
|
||||
| Name | Notes |
|
||||
|------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| AP | Signifies that this client is a reference client, its usefulness is mostly in debugging to compare client behaviours more easily. |
|
||||
| IgnoreGame | Deprecated. See Tracker and TextOnly. Tells the server to ignore the "game" attribute in the [Connect](#Connect) packet. |
|
||||
| IgnoreGame | Deprecated. See Tracker and TextOnly. Tells the server to ignore the "game" attribute in the [Connect](#connect) packet. |
|
||||
| DeathLink | Client participates in the DeathLink mechanic, therefore will send and receive DeathLink bounce packets |
|
||||
| Tracker | Tells the server that this client will not send locations and is actually a Tracker. When specified and used with empty or null `game` in [Connect](#connect), game and game's version validation will be skipped. |
|
||||
| TextOnly | Tells the server that this client will not send locations and is intended for chat. When specified and used with empty or null `game` in [Connect](#connect), game and game's version validation will be skipped. |
|
||||
@@ -6,26 +6,20 @@ required to send and receive items between the game and server.
|
||||
|
||||
Client implementation is out of scope of this document. Please refer to an
|
||||
existing game that provides a similar API to yours.
|
||||
Refer to the following documents as well:
|
||||
- [network protocol.md](https://github.com/ArchipelagoMW/Archipelago/blob/main/docs/network%20protocol.md)
|
||||
- [adding games.md](https://github.com/ArchipelagoMW/Archipelago/blob/main/docs/adding%20games.md)
|
||||
|
||||
Archipelago will be abbreviated as "AP" from now on.
|
||||
|
||||
|
||||
## Language
|
||||
|
||||
AP worlds are written in python3.
|
||||
Clients that connect to the server to sync items can be in any language that
|
||||
allows using WebSockets.
|
||||
|
||||
|
||||
## Coding style
|
||||
|
||||
AP follows all the PEPs. When in doubt use an IDE with coding style
|
||||
linter, for example PyCharm Community Edition.
|
||||
|
||||
|
||||
## Docstrings
|
||||
|
||||
Docstrings are strings attached to an object in Python that describe what the
|
||||
@@ -40,7 +34,6 @@ class MyGameWorld(World):
|
||||
website."""
|
||||
```
|
||||
|
||||
|
||||
## Definitions
|
||||
|
||||
This section will cover various classes and objects you can use for your world.
|
||||
@@ -63,7 +56,7 @@ for your world specifically on the webhost.
|
||||
`theme` to be used for your game specific AP pages. Available themes:
|
||||
| dirt | grass (default) | grassFlowers | ice | jungle | ocean | partyTime | stone |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| <img src="img/theme_dirt.JPG" width="100"> | <img src="img/theme_grass.JPG" width="100"> | <img src="img/theme_grassFlowers.JPG" width="100"> | <img src="img/theme_ice.JPG" width="100"> | <img src="img/theme_jungle.JPG" width="100"> | <img src="img/theme_ocean.JPG" width="100"> | <img src="img/theme_partyTime.JPG" width="100"> | <img src="img/theme_stone.JPG" width="100"> |
|
||||
| <img src="_static/theme_dirt.JPG" width="200"> | <img src="_static/theme_grass.JPG" width="200"> | <img src="_static/theme_grassFlowers.JPG" width="200"> | <img src="_static/theme_ice.JPG" width="200"> | <img src="_static/theme_jungle.JPG" width="200"> | <img src="_static/theme_ocean.JPG" width="200"> | <img src="_static/theme_partyTime.JPG" width="200"> | <img src="_static/theme_stone.JPG" width="200"> |
|
||||
|
||||
`bug_report_page` (optional) can be a link to a bug reporting page, most likely a GitHub issue page, that will be placed by the site to help direct users to report bugs.
|
||||
|
||||
|
Before Width: | Height: | Size: 50 KiB After Width: | Height: | Size: 50 KiB |
|
Before Width: | Height: | Size: 35 KiB After Width: | Height: | Size: 35 KiB |
|
Before Width: | Height: | Size: 81 KiB After Width: | Height: | Size: 81 KiB |
|
Before Width: | Height: | Size: 47 KiB After Width: | Height: | Size: 47 KiB |
|
Before Width: | Height: | Size: 65 KiB After Width: | Height: | Size: 65 KiB |
|
Before Width: | Height: | Size: 40 KiB After Width: | Height: | Size: 40 KiB |
|
Before Width: | Height: | Size: 64 KiB After Width: | Height: | Size: 64 KiB |
|
Before Width: | Height: | Size: 83 KiB After Width: | Height: | Size: 83 KiB |
|
Before Width: | Height: | Size: 79 KiB After Width: | Height: | Size: 79 KiB |
|
Before Width: | Height: | Size: 56 KiB After Width: | Height: | Size: 56 KiB |
|
Before Width: | Height: | Size: 38 KiB After Width: | Height: | Size: 38 KiB |
|
Before Width: | Height: | Size: 82 KiB After Width: | Height: | Size: 82 KiB |
|
Before Width: | Height: | Size: 65 KiB After Width: | Height: | Size: 65 KiB |
|
Before Width: | Height: | Size: 209 KiB After Width: | Height: | Size: 209 KiB |
|
Before Width: | Height: | Size: 216 KiB After Width: | Height: | Size: 216 KiB |
|
Before Width: | Height: | Size: 214 KiB After Width: | Height: | Size: 214 KiB |
|
Before Width: | Height: | Size: 214 KiB After Width: | Height: | Size: 214 KiB |
|
Before Width: | Height: | Size: 257 KiB After Width: | Height: | Size: 257 KiB |
|
Before Width: | Height: | Size: 221 KiB After Width: | Height: | Size: 221 KiB |
|
Before Width: | Height: | Size: 245 KiB After Width: | Height: | Size: 245 KiB |
|
Before Width: | Height: | Size: 193 KiB After Width: | Height: | Size: 193 KiB |
56
docs/sphinx/conf.py
Normal file
@@ -0,0 +1,56 @@
|
||||
# Configuration file for the Sphinx documentation builder.
|
||||
#
|
||||
# This file only contains a selection of the most common options. For a full
|
||||
# list see the documentation:
|
||||
# https://www.sphinx-doc.org/en/master/usage/configuration.html
|
||||
|
||||
# -- Path setup --------------------------------------------------------------
|
||||
|
||||
# If extensions (or modules to document with autodoc) are in another directory,
|
||||
# add these directories to sys.path here. If the directory is relative to the
|
||||
# documentation root, use os.path.abspath to make it absolute, like shown here.
|
||||
#
|
||||
import os
|
||||
import sys
|
||||
sys.path.insert(0, os.path.abspath('../..'))
|
||||
|
||||
# -- Project information -----------------------------------------------------
|
||||
|
||||
project = 'Archipelago'
|
||||
copyright = '2022, Archipelago Team and Contributors'
|
||||
author = 'Archipelago Team and Contributors'
|
||||
|
||||
|
||||
# -- General configuration ---------------------------------------------------
|
||||
|
||||
# Add any Sphinx extension module names here, as strings. They can be
|
||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||
# ones.
|
||||
extensions = [
|
||||
"myst_parser",
|
||||
"sphinxcontrib.mermaid",
|
||||
"sphinx.ext.autodoc",
|
||||
"sphinx.ext.autosummary",
|
||||
]
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
templates_path = ['_templates']
|
||||
|
||||
# List of patterns, relative to source directory, that match files and
|
||||
# directories to ignore when looking for source files.
|
||||
# This pattern also affects html_static_path and html_extra_path.
|
||||
exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
|
||||
|
||||
myst_heading_anchors = 4
|
||||
|
||||
# -- Options for HTML output -------------------------------------------------
|
||||
|
||||
# The theme to use for HTML and HTML Help pages. See the documentation for
|
||||
# a list of builtin themes.
|
||||
#
|
||||
html_theme = 'alabaster'
|
||||
|
||||
# Add any paths that contain custom static files (such as style sheets) here,
|
||||
# relative to this directory. They are copied after the builtin static files,
|
||||
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||
html_static_path = ['_static']
|
||||
70
docs/sphinx/index.md
Normal file
@@ -0,0 +1,70 @@
|
||||
% Archipelago documentation master file, created by
|
||||
% sphinx-quickstart on Wed Jul 6 20:09:51 2022.
|
||||
% You can adapt this file completely to your liking, but it should at least
|
||||
% contain the root `toctree` directive.
|
||||
|
||||
Welcome to Archipelago's Technical Documentation!
|
||||
=================================================
|
||||
|
||||
## What is Archipelago?
|
||||
Archipelago provides a generic framework for developing multiworld capability for game randomizers.
|
||||
In all cases, presently, Archipelago is also the randomizer itself.
|
||||
|
||||
Archipelago is end-user facing software intended to facilitate randomizer and multiworld play for a variety of
|
||||
supported games.
|
||||
|
||||
Archipelago presently supports the following games:
|
||||
* The Legend of Zelda: A Link to the Past
|
||||
* Factorio
|
||||
* Minecraft
|
||||
* Subnautica
|
||||
* Slay the Spire
|
||||
* Risk of Rain 2
|
||||
* The Legend of Zelda: Ocarina of Time
|
||||
* Timespinner
|
||||
* Super Metroid
|
||||
* Secret of Evermore
|
||||
* Final Fantasy
|
||||
* Rogue Legacy
|
||||
* VVVVVV
|
||||
* Raft
|
||||
* Super Mario 64
|
||||
* Meritous
|
||||
* Super Metroid/Link to the Past combo randomizer (SMZ3)
|
||||
* ChecksFinder
|
||||
* ArchipIDLE
|
||||
* Hollow Knight
|
||||
* The Witness
|
||||
* Sonic Adventure 2: Battle
|
||||
* Starcraft 2: Wings of Liberty
|
||||
* Donkey Kong Country 3
|
||||
* Dark Souls 3
|
||||
|
||||
For more information on the technical architecture of Archipelago,
|
||||
please refer to the [Archipelago Technical Architecture](Architecture.md) document.
|
||||
|
||||
## Contributing to Archipelago
|
||||
Contributions to the Archipelago code are welcome and dearly appreciated. Contributions may occur as changes to website
|
||||
content, changes to Archipelago core code, additions of game integrations, or alterations to website functionality.
|
||||
|
||||
Please visit our [contributing guidelines on our GitHub README](https://github.com/ArchipelagoMW/Archipelago#contributing)
|
||||
for some more information on what may be expected.
|
||||
|
||||
For information on contributing a game integration, check out our [document on adding games to Archipelago](./AddingGames.md).
|
||||
|
||||
## Table of Contents
|
||||
```{toctree}
|
||||
---
|
||||
maxdepth: 2
|
||||
caption: "Documentation contents:"
|
||||
---
|
||||
AddingGames
|
||||
WorldAPI
|
||||
NetworkProtocol
|
||||
NetworkDiagram
|
||||
```
|
||||
|
||||
## Indices and tables
|
||||
* {ref}`genindex`
|
||||
* {ref}`modindex`
|
||||
* {ref}`search`
|
||||
35
docs/sphinx/make.bat
Normal file
@@ -0,0 +1,35 @@
|
||||
@ECHO OFF
|
||||
|
||||
pushd %~dp0
|
||||
|
||||
REM Command file for Sphinx documentation
|
||||
|
||||
if "%SPHINXBUILD%" == "" (
|
||||
set SPHINXBUILD=sphinx-build
|
||||
)
|
||||
set SOURCEDIR=.
|
||||
set BUILDDIR=_build
|
||||
|
||||
if "%1" == "" goto help
|
||||
|
||||
%SPHINXBUILD% >NUL 2>NUL
|
||||
if errorlevel 9009 (
|
||||
echo.
|
||||
echo.The 'sphinx-build' command was not found. Make sure you have Sphinx
|
||||
echo.installed, then set the SPHINXBUILD environment variable to point
|
||||
echo.to the full path of the 'sphinx-build' executable. Alternatively you
|
||||
echo.may add the Sphinx directory to PATH.
|
||||
echo.
|
||||
echo.If you don't have Sphinx installed, grab it from
|
||||
echo.https://www.sphinx-doc.org/
|
||||
exit /b 1
|
||||
)
|
||||
|
||||
%SPHINXBUILD% -M %1 %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O%
|
||||
goto end
|
||||
|
||||
:help
|
||||
%SPHINXBUILD% -M help %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O%
|
||||
|
||||
:end
|
||||
popd
|
||||
4
docs/sphinx/requirements.txt
Normal file
@@ -0,0 +1,4 @@
|
||||
sphinx==5.0.2
|
||||
sphinx_rtd_theme==1.0.0
|
||||
readthedocs-sphinx-search==0.1.2
|
||||
myst-parser==0.18
|
||||
@@ -120,67 +120,87 @@ class World(metaclass=AutoWorldRegister):
|
||||
"""A World object encompasses a game's Items, Locations, Rules and additional data or functionality required.
|
||||
A Game should have its own subclass of World in which it defines the required data structures."""
|
||||
|
||||
option_definitions: Dict[str, Option[Any]] = {} # link your Options mapping
|
||||
game: str # name the game
|
||||
topology_present: bool = False # indicate if world type has any meaningful layout/pathing
|
||||
option_definitions: Dict[str, Option[Any]] = {}
|
||||
""" link your Options mapping """
|
||||
|
||||
game: str
|
||||
""" name of the game the world is for """
|
||||
|
||||
topology_present: bool = False
|
||||
""" indicate if world type has any meaningful layout/pathing """
|
||||
|
||||
# gets automatically populated with all item and item group names
|
||||
all_item_and_group_names: FrozenSet[str] = frozenset()
|
||||
""" gets automatically populated with all item and item group names """
|
||||
|
||||
# map names to their IDs
|
||||
item_name_to_id: Dict[str, int] = {}
|
||||
""" map item names to their IDs """
|
||||
|
||||
location_name_to_id: Dict[str, int] = {}
|
||||
""" map location names to their IDs """
|
||||
|
||||
# maps item group names to sets of items. Example: "Weapons" -> {"Sword", "Bow"}
|
||||
item_name_groups: Dict[str, Set[str]] = {}
|
||||
""" maps item group names to sets of items. Example: "Weapons" -> {"Sword", "Bow"} """
|
||||
|
||||
# increment this every time something in your world's names/id mappings changes.
|
||||
# While this is set to 0 in *any* AutoWorld, the entire DataPackage is considered in testing mode and will be
|
||||
# retrieved by clients on every connection.
|
||||
data_version: int = 1
|
||||
"""increment this every time something in your world's names/id mappings changes.
|
||||
While this is set to 0 in *any* AutoWorld, the entire DataPackage is considered in testing mode and will be
|
||||
retrieved by clients on every connection.
|
||||
"""
|
||||
|
||||
# override this if changes to a world break forward-compatibility of the client
|
||||
# The base version of (0, 1, 6) is provided for backwards compatibility and does *not* need to be updated in the
|
||||
# future. Protocol level compatibility check moved to MultiServer.min_client_version.
|
||||
required_client_version: Tuple[int, int, int] = (0, 1, 6)
|
||||
""" override this if changes to a world break forward-compatibility of the client
|
||||
The base version of (0, 1, 6) is provided for backwards compatibility and does *not* need to be updated in the
|
||||
future. Protocol level compatibility check moved to MultiServer.min_client_version.
|
||||
"""
|
||||
|
||||
# update this if the resulting multidata breaks forward-compatibility of the server
|
||||
required_server_version: Tuple[int, int, int] = (0, 2, 4)
|
||||
""" update this if the resulting multidata breaks forward-compatibility of the server """
|
||||
|
||||
hint_blacklist: FrozenSet[str] = frozenset() # any names that should not be hintable
|
||||
hint_blacklist: FrozenSet[str] = frozenset()
|
||||
""" any names that should not be hintable """
|
||||
|
||||
# NOTE: remote_items and remote_start_inventory are now available in the network protocol for the client to set.
|
||||
# These values will be removed.
|
||||
# if a world is set to remote_items, then it just needs to send location checks to the server and the server
|
||||
# sends back the items
|
||||
# if a world is set to remote_items = False, then the server never sends an item where receiver == finder,
|
||||
# the client finds its own items in its own world.
|
||||
remote_items: bool = True
|
||||
""" NOTE: remote_items and remote_start_inventory are now available in the network protocol for the client to set.
|
||||
These values will be removed.
|
||||
if a world is set to remote_items, then it just needs to send location checks to the server and the server
|
||||
sends back the items
|
||||
if a world is set to remote_items = False, then the server never sends an item where receiver == finder,
|
||||
the client finds its own items in its own world.
|
||||
"""
|
||||
|
||||
# If remote_start_inventory is true, the start_inventory/world.precollected_items is sent on connection,
|
||||
# otherwise the world implementation is in charge of writing the items to their output data.
|
||||
remote_start_inventory: bool = True
|
||||
""" If remote_start_inventory is true, the start_inventory/world.precollected_items is sent on connection,
|
||||
otherwise the world implementation is in charge of writing the items to their output data.
|
||||
"""
|
||||
|
||||
# For games where after a victory it is impossible to go back in and get additional/remaining Locations checked.
|
||||
# this forces forfeit: auto for those games.
|
||||
forced_auto_forfeit: bool = False
|
||||
""" For games where after a victory it is impossible to go back in and get additional/remaining Locations checked.
|
||||
this forces forfeit: auto for those games.
|
||||
"""
|
||||
|
||||
# Hide World Type from various views. Does not remove functionality.
|
||||
hidden: bool = False
|
||||
""" Hide World Type from various views. Does not remove functionality. """
|
||||
|
||||
# see WebWorld for options
|
||||
web: WebWorld = WebWorld()
|
||||
|
||||
# autoset on creation:
|
||||
world: "MultiWorld"
|
||||
""" autoset on creation """
|
||||
|
||||
player: int
|
||||
""" autoset on creation """
|
||||
|
||||
# automatically generated
|
||||
item_id_to_name: Dict[int, str]
|
||||
location_id_to_name: Dict[int, str]
|
||||
""" automatically generated inverse of item_name_to_id """
|
||||
|
||||
item_names: Set[str] # set of all potential item names
|
||||
location_names: Set[str] # set of all potential location names
|
||||
location_id_to_name: Dict[int, str]
|
||||
""" automatically generated inverse of location_name_to_id """
|
||||
|
||||
item_names: Set[str]
|
||||
""" set of all potential item names """
|
||||
|
||||
location_names: Set[str]
|
||||
""" set of all potential location names """
|
||||
|
||||
zip_path: Optional[pathlib.Path] = None # If loaded from a .apworld, this is the Path to it.
|
||||
__file__: str # path it was loaded from
|
||||
@@ -284,8 +304,8 @@ class World(metaclass=AutoWorldRegister):
|
||||
return item.name
|
||||
return None
|
||||
|
||||
# called to create all_state, return Items that are created during pre_fill
|
||||
def get_pre_fill_items(self) -> List["Item"]:
|
||||
""" called to create all_state, return Items that are created during pre_fill """
|
||||
return []
|
||||
|
||||
# following methods should not need to be overridden.
|
||||
|
||||
@@ -5,14 +5,15 @@ import typing
|
||||
|
||||
folder = os.path.dirname(__file__)
|
||||
|
||||
__all__ = {
|
||||
__all__ = [
|
||||
"lookup_any_item_id_to_name",
|
||||
"lookup_any_location_id_to_name",
|
||||
"network_data_package",
|
||||
"AutoWorldRegister",
|
||||
"world_sources",
|
||||
"folder",
|
||||
}
|
||||
"World"
|
||||
]
|
||||
|
||||
if typing.TYPE_CHECKING:
|
||||
from .AutoWorld import World
|
||||
|
||||