-
Notifications
You must be signed in to change notification settings - Fork 20
Concepts
Slime Rancher is a complicated game under the hood, and there's a lot of things about its codebase that need to be understood before you can start creating mods. This page serves as a repository for common concepts needed for modding Slime Rancher.
These are miscellaneous classes that are important to know for modding
An Enum containing the ID's of every actor in the game, such as slimes, food, toys, plorts, and slime science resources.
Identifiable.Id's are separated into different classes. For example, all slimes are put into a SLIME_CLASS, and calling Identifiable.IsSlime on a slimes Identifiable.Id, it would return true.
Other notable Id classes that serve a similar purpose to Identifiable.Id include Gadget.Id, LandPlot.Id, PediaDirector.Id and SpawnResource.Id
Instead of inventories, Slime Rancher uses Ammo, which serves the exact same purpose as inventories. Whenever Ammo is referred to, it is synonymous with inventory. See SRML.SR.AmmoRegistry
Every object that gets saved, and isn't static (it moves around) is known as an Actor. Every actor has a component called Identifiable that stores the actors type ID. For example, a Pink Slime has the Id, Identifiable.Id.PINK_SLIME, where as a hen hen has the Id, Identifiable.Id.HEN. This is how the game tells objects of different types apart, by their identifiables. Actors of a particular type/Identifiable.Id also have a prefab object that all instances of actors of that type come from, which can be found in the LookupDirector. Every actor also has a numeric ID (stored as a long) that is different for every individual actor (unlike the Identifiable.Id, which only changes between different types of actors), this ID is used for saving the actors to the save file.
- Actor - Any object with persistent state that isn't static
- Identifiable - A component on all actors that acts as an identifier for the actor, storing that actors type, and numeric id
- Identifiable.Id/Type Id - The type of the Actor
- Actor Id - The numeric id belong to the actor
Various objects in the game interact with the games save system through special classes known as Data Models. These are state holding classes that are stored in the GameModel. One great example of an object that uses data models are Actors. Whenever an actor is spawned from it's prefab, it gets registered in the GameModel and the gamemodel creates an ActorModel and gives it to the Actor. The actor can have components on it that extend the interface ActorModel.Participant which has methods that get called when the gamemodel initializes that actors model. There are different types of actor models, that are given to actors depending on their Identifiable.id. For example, Slimes all get a SlimeModel while food gets a ProduceModel. Actor models store everything about an actor, from their actor id to their position, velocity, and all sorts of other data. But not only actors have data models, there are also GadgetModels, LandPlotModels, and more. When saving time comes, the GameModel serializes all the data present in it and saves it to disk, by using the Data Models.
- Data Model - a state holding class that the game uses to connect the save system and actual objects in the game
- ActorModel - a type of Data Model made specifically for actors
- Participant - a component on an object that uses and initializes a Data Model for an object. (NOTE: an object can have many many participants, even Identifiable is a participant)
TODO
Slime Rancher uses singleton classes known as Contexts to store common data and behaviours the game needs to function. The two major contexts Slime Rancher has are the GameContext and the SceneContext. These contexts contain many fields leading to Director classes, that each control a portion of the game. Accessing these Directors through their respective Contexts is how we trigger and change behaviours for modding.
GameContext is a game-wide context that contains code that isn't specific to any particular gamestate (ie main menu vs in a game)
Can be accessed with GameContext.Instance after the preload step
Here is a list of some of the important Directors it contains:
The LookupDirector manages game assets and maps prefabs to their ID's. It contains methods for getting Actors, Gadgets, LandPlots, Toys, Vac Entries, Liquids, Gordos, and more. Use this class if you want to access game assets and use SRML.SR.LookupRegistry to add new assets to it.
SlimeDefinitions is a database of all slimes and their respective definitions. Use this class if you want to access slimes and their definitions and change information such as diets. Use SRML.SR.SlimeRegistry to add new SlimeDefinitions
Handles saving and loading of saved games as well as game settings.
Handles localization and languages. You can register a bundle listener that gets called when the MessageDirector is ready, which is useful for anything that requires localization. Use SRML.SR.TranslationPatcher to register new localizations in addition to classes in the SRML.SR.Translations namespace.
Used for generating common UI instances, such as purchasable UI's, error dialogs, and more. Use this class for generating UI instances. Use SRML.SR.PurchasableUIRegistry for adding new purchase buttons to existing UI's
Handles game input.
This context holds code and data specific to the scene, and not the whole game. Its state is reset every time the scene changes, which includes loading a game, and exiting from a game to the main menu.
It can be accessed with SceneContext.Instance but some things may not have a valid state depending on the current scene.
For a guaranteed valid SceneContext add a callback to SRCallbacks.OnSavedGameLoaded
Holds all data about the player, such as their ammo/inventory, health, upgrades, and more
Handles the plort market and calculates plort values as time progresses
Handles fast forwarding and game time, as well as pausing and unpausing.
Handles generation and upkeep for Ranch Exchanges
Handles the slimepedia. Use it to get information about what's unlocked and what isn't, as well as other pedia related tasks. Adding new pedia entries can be done through the SRML.SR.PediaRegistry class
Handles and generates the tutorials that you see ingame.
Handles Starmail. Can add new mail entries with SRML.SR.MailRegistry class
Handles progress tracking.
Handles gadgets and blueprints, as well as most slime science related things. Can add new Gadgets through SRML.SR.GadgetRegistry
Handles loading and unloading of regions and zones.
Holds all Data Models in use by the current save. Registers and unregisters actors and other things with persistent data, and can be used to access game state in certain situations