Modding
Furniture Modding is a separate page |
Material Modding is a separate page |
Code Modding is a separate page |
Modding in Software Inc. is completely data driven. Software Inc. loads TyD files found in the "Mods" folder of the root of the game when it launches.
A mod should be placed in its own folder in the "Mods" folder and can optionally contain each of the following folders: "CompanyTypes", "NameGenerators" and "SoftwareTypes".
The root of your mod can additionally include a Personalities.tyd file to add new personalities to the game.
Debugging console
The debugging console is enabled by binding the console key at the bottom of the key binding menu in the options window.
Helpful commands
- INSTA_DEVELOP_DESIGN - Instantly releases whatever is in the design document window, skipping design and dev phases (Only works for modded software)
- RELOAD_MOD X - Reloads mod named X. Note that this does not affect the currently running game, if there is any
- CHECK_SPEC_REP X - Checks whether all specialization levels are used across all software when mod named X is loaded, which would otherwise make some education worthless
- TEST_DEV_MOD X Y Z - Prints out balancing information for Software Category Z in Software Y in mod X. This tells you if the player can reach 100% interest with any submarket targeting
- LIST_SCOPE_MEMBERS X - Prints out all functions and variables available for the type X, to use when making level 3 feature scripts
- COMPARE_LOCALIZATION X Y - Compares what has changed between between localization X and Y, Y should almost always be "English"
- CONVERT_LOCALIZATION_TYD X - Converts localization named X from XML to TyD
- RELOAD_LOCALIZATION - Reloads all localizations, but does not update UI instantly when in-game
In-game content
These are zip files of the software types, company types, name generators and personality types currently in the game:
Alpha 11 changes
If you're coming from pre-Alpha 11 modding, this section will probably be relevant, as the design philosophy of software in Alpha 11 is incompatible with previous versions.
Feature evolution
Features can no longer depend on each other. You can't design your software in a way that relies on features evolving or deprecating old features. Features are more abstract in Alpha 11 and rely instead on Tech levels to control their evolution. An example would be PC speaker, 8-bit audio and HD audio from Alpha 10. In Alpha 11 you just have "Audio" and its tech level determines its perceived complexity.
Why?
On a surface level this might seem like a step back in terms of gameplay depth, but it actually opens up a new layer of complexity. The old system wasn't really deep in any meaningful way to begin with, since the player would always end up just pressing "Select all" and none of the intricacies of the feature dependencies were very obvious or satisfying. Some benefits of the new system include:
- The player will never run out of new features
- The player will never run out of things to research and there will always be research available
- The complexity has been moved from obscure interdependencies to several new systems the player can actively engage with
- The tech level system is a steppingstone to adding the updates/expansion mechanic, which would not have been possible with the old feature system
Moving forward
Features should be a lot more abstract than before. They should represent aspects of a product that appeals to different submarkets to various degrees, rather than very time period specific add-ons. The game is balanced towards the player deciding on which markets they want to target and selecting features that fit that goal. Ideally you would have features that don't always fit in a product, which the player would want to leave out. Features that should always be present, like Audio playback, are represented as "SpecFeatures" or specialization features, which can be specified as mandatory and work as containers for other features with the same specialization.
Software types
Software types are the types of software you can choose to develop in Software Inc. in the design document window. Software types can be added to the game by creating an TyD file in the "SoftwareTypes" folder.
Overview
Elements
A software type TyD table should contain the following elements:
Name | The name of the software as it will appear in dropdown lists, etc. |
Override | If this is set to True all elements are optional and will override the content of a software type by the same name. You can use this to override some values of the built-in software types. Note that if you override the Features list, you will delete all features from the software type. If it is set to Delete, it will delete the softwaretype of the same name, from the game. This should be omitted if you are just adding a new software type. |
Category | How the field of the software will be referred to in articles, e.g. games are categorized as "Gaming" |
Categories | The categories for the software type. This can be omitted to make the game create a Default category. |
Description | The contents of the tooltip that will appear when hovering over the software type in the dropdown menu in the design document window. |
Unlock | Which year this software type will unlock, e.g. Unlock 1995 |
Random | How much sales will vary. When a product is released, a random number is chosen and it is weighted using this number, and it will be multiplied for all sales. As an example, for games it is 0.5, since you can't count on good sales for a game, but for operating systems, it is 0, since they are generally in demand and necessary for a computer to work, so sales won't vary that much. Note that the effect of this value is very small as of Alpha 11. |
IdealPrice | How much products of this type should ideally cost at 100% quality and interest. This should be omitted if you want to control the ideal pricing per category. |
OptimalDevTime | How many months this product should ideally take to make (This is in 1 employee months, meaning the value is not scaled by having a team working on it). This also controls how many features the player needs to select to satisfy a submarket. This is 40 for games and 75 for operating systems. |
Popularity | How popular a software type is, which limits the maximum amount of potential consumers. Computer operating systems have 1 and Role Playing Games have 0.6. (Ignored if software type has categories defined) |
Retention | How long products keep their interest after release and how long people will use the product in months. Computer operating systems have 72 and Role Playing Games have 24. (Ignored if software type has categories defined) |
Iterative | How likely AI companies are to develop sequels for this type of software, between 0 and 1. (Ignored if software type has categories defined) |
OSSupport | Set to True if this product requires support by an operating system. If you only want support by specific operating system categories you can write it out like Computer or in list form like [ Computer; Console ]. If your software is not operating system dependent just omit this record. |
OneClient | Whether this software is for contract work. |
InHouse | Whether you can lock this software to your own company. This makes sense for tool dependencies, like Audio and 3D tools, but not for customer facing products such as games for example. |
NameGenerator | The name generator to use for simulated companies or for when the player clicks the name button in the design document. (Will be used for all software categories which don't have one defined) |
SubmarketNames | A list of three submarket names, e.g. [ Gameplay; Graphics; Story ]. Submarket ratios you define in categories and features should be in the same order you define the names in. |
Features | All features that this software can implement. |
Example
Note that this product will have a maximum devtime of 12, but the optimal is set to 25, so the player won't have enough features to reach 100% submarket satisfaction, especially since the features doesn't cover all submarkets properly. You can use the TEST_DEV_MOD console command to make sure your software type can satisfying its submarkets.
SoftwareType { Name "Test Software" Category Testing Description "This is part of a test mod. If you develop a perfect version, 50% of the population will want it for about $50, but less than 10% might randomly not want it." Random 0.1 IdealPrice 50 OptimalDevTime 25 OSSupport Computer OneClient False InHouse False SubmarketNames [ TestMarket1; TestMarket2; TestMarket3 ] Categories [ { Name "Test category" Description "This is a test category" Popularity 0.5 Submarkets [ 1; 3; 1 ]#20%, 60%, 20% Retention 24 TimeScale 1 Iterative 0.75 NameGenerator testgen } ] Features [ { Name "Test feat 1" Spec System Description "This feature represents the system aspect of the product and cannot be deselected" DevTime 3 CodeArt 1 Submarkets [ 1; 0; 1 ]#50%, 0%, 50% Features [ { Name "Test subfeat 1" Description "This feature requires a level 1 System designer/programmer to be finished" DevTime 3 Level 1 CodeArt 1 Submarkets [ 0; 1; 0 ] } { Name "Test subfeat 2" Description "This feature will cost the owner $1000 per day when it is released" DevTime 2 Level 3 CodeArt 1 Submarkets 0 #No submarkets needed for level 3 features Script_EndOfDay "Product.DevCompany.MakeTransaction(-1000, Bills, \"Owned\");" } ] } { Name "Test feat 2" Spec Audio Dependencies "Audio Tool" Optional True Description "This feature can be deselected, completely removing Audio features and Audio Tool dependencies from the product" DevTime 4 CodeArt 1 Submarkets [ 0; 1; 3 ]#0%, 25%, 75% } ] }
SpecFeatures
SpecFeatures or Specialization Features are features that map to a specialization (3D, 2D, Audio, etc.), which employees can specialize in. You can only have 1 SpecFeature per specialization, but you don’t need to have one for each specialization. You can make up your own specializations and the game will add them automatically.
SpecFeatures are the foundation that smaller features (SubFeatures) build on. All features have a level which determines employee education requirements. SpecFeatures are level 0, meaning everyone can work on them, but they are not as effective as level 1 or 2 features for satisfying the submarkets.
Values
Name | The name of the feature as it will appear in feature panel in the design document window |
Spec | Which specialization this feature maps to. This can be 2D, 3D, Network, etc. You can add new specializations to the game using this record by simply writing whatever you want. |
Description | The contents of the tooltip that will appear when hovering over the feature in the design document window. |
Unlock | Which year this feature will unlock, e.g. Unlock 1995. Specializations will unlock, when the first feature which uses it unlocks. |
DevTime | How many months it takes to develop this feature |
Submarkets | A list of 3 values determining the submarket ratio, i.e. how this feature satisfies the submarkets. These three values are normalized, so you can put in any number. 3, 4 and 5 would result in 3/12, 4/12 and 5/12. |
CodeArt | The coding to art balancing of the feature. 1 will mean this feature only requires programmers whereas 0 will mean it only requires artists, and 0.5 means a little bit of both. |
Server | How many mbps this feature will need per active user. It is scaled with time using the formula 1+log10(year-1969). MMO uses 0.002, which would be around 5 gbps at any given time for a 1 million user game in 2010, which might change in the future. |
Optional | If you want the player to be able to toggle this feature off, just add the record Optional True, otherwise you can omit this record. |
SoftwareCategories | Optional record that limits the feature to a certain software category of its parent software type. You can specify a year with each category you list, e.g. [ [Computer; 1995]; [ Console; 2000 ] ], however if you just want the feature to only be available for some categories, you can write them out in a list like so: [ Computer; Console], which is equivalent to unlocking at year 0. Having this record will override it in all its subfeatures. |
Features | This is the list of SubFeatures that belongs to this SpecFeature. |
SubFeatures
SubFeature are addons to the main SpecFeatures, they fit in the same specialization as the SpecFeature they belong to, but they satisfy submarkets more effectively, meaning they need less devtime to add more satisfaction.
Values
Name | The name of the feature as it will appear in feature panel in the design document window |
Description | The contents of the tooltip that will appear when hovering over the feature in the design document window. |
Level | The level of the feature, which controls who can work on it. Level 2 features give more submarket satisfaction than level 1 features. Level 3 features don't satisfy submarkets at all, but they have custom scripts. |
Unlock | Which year this feature will unlock, e.g. Unlock 1995. |
DevTime | How many months it takes to develop this feature |
Submarkets | A list of 3 values determining the submarket ratio, i.e. how this feature satisfies the submarkets. These three values are normalized, so you can put in any number. 3, 4 and 5 would result in 3/12, 4/12 and 5/12. |
CodeArt | The coding to art balancing of the feature. 1 will mean this feature only requires programmers whereas 0 will mean it only requires artists, and 0.5 means a little bit of both. |
Server | How many mbps this feature will need per active user. It is scaled with time using the formula 1+log10(year-1969). MMO uses 0.002, which would be around 5 gbps at any given time for a 1 million user game in 2010, which might change in the future. |
SoftwareCategories | Optional record that limits the feature to a certain software category of its parent software type. You can specify a year with each category you list, e.g. [ [Computer; 1995]; [ Console; 2000 ] ], however if you just want the feature to only be available for some categories, you can write them out in a list like so: [ Computer; Console], which is equivalent to unlocking at year 0. This record will be ignored if the parent SpecFeature has it defined. |
Script_EntryPoint | Scripts for level 3 features, read below. |
Level 3 features
Level 3 features do not satisfy submarkets at all, but they have custom scripts attached that change how the game works in some way. Scripting works using a programming language developed specifically for Software Inc.
You add scripts to features by adding a Script record, which consists of Script_ and then the name of entry point where you want your script to be executed, and then your script. Each entry point has a different scope, which determines which variables you can interact with. These entry points currently exist:
Entry point | Description | Scope |
Script_EndOfDay | Executes after the market has finished simulating every day after the product is released. | ProductScope |
Script_AfterSales | Executes right after a products sales units have been calculated. | SaleScope |
Script_OnRelease | Executes when the product has been created, before it is actually registered in the market. | ProductScope |
Script_NewCopies | Executes when new physical copies have been shipped for a product. (i.e. not sold yet) | CopyScope |
Script_WorkItemChange | Executed whenever a task has been created or stopped, that is related to the product. You can use the is keyword to figure out what kind of task you're dealing with, e.g. if (WorkItem is MarketingPlan). | DevScope |
To figure out which variables you have access to, you can use the LIST_SCOPE_MEMBERS console command with the name of the scope you want to check out, e.g. LIST_SCOPE_MEMBERS CopyScope. Note that you can use dot notation to drill down into a scope, e.g. LIST_SCOPE_MEMBERS CopyScope.Product.
You can either write your scripts directly in your TyD file as such:
Script_EndOfDay "if (Product.GetCashflow(false).Last() > 100) { Product.DevCompany.MakeTransaction(-Product.GetCashflow(false).Last() * 0.1, Bills); } //Pay 10% of last days income if it is more than $100"
Or you can put your script in separate files and refer to them relative to your mod root folder, by starting with a forward slash:
Script_EndOfDay "/Scripts/MyScript.txt"
Finally, all SoftwareProduct's have their own local variables that you can read and write to for your scripts, just use Product.GetVar(VariableName, DefaultValue) and Product.PutVar(VariableName, Value).
Script example
This script is used in the microphone surveillance feature of the Operating System SoftwareType:
if (Product.GetVar("MicMining", true)) //Check if player has been caught { Product.Bugs = Max(0, Product.Bugs - Product.Userbase * 0.01); //Remove 1 bug from product for each 100th active user if (Random() * Product.Userbase > 1000000 * Product.Category.Popularity) //Random chance of getting caught { LaunchLawsuit("SpyingOnUsers", Product.Sum, 1); //Create anonymous lawsuit Product.DevCompany.AddFans(-Product.Userbase, Product.Category); //Remove fans and market recognition from player in category Product.Userbase = Product.Userbase * 0.05; //Remove 95% of active users Product.KillAwareness(); //Remove all marketing Product.PutVar("MicMining", false); //Mark player as caught for this product } }
You should download the mod data zip and check out examples of other scripts in the other vanilla SoftwareTypes.
Software categories
Software categories are defined in the Categories list of the SoftwareType table. Categories enable software specialization, e.g. OS/Console/Phone Operating systems. It is completely optional and a "Default" category will be used in case it is omitted from the software definition.
Values
Name | This is the name of the category |
Description | What will be shown when hovering over the category in the design document |
Unlock | Which year this software category will unlock, e.g. <Unlock>1995</Unlock> |
Popularity | How popular a software category is, which limits the maximum amount of income. Computer operating systems have 1 and Role Playing Games have 0.6. |
Submarkets | The ratio of submarkets for this category. E.g. [ 1; 3; 4 ] will result in the third submarket making up 4 / (1 + 3 + 4) = 50% of the consumer population for this product, while the first only makes up 12.5%. |
TimeScale | How long it will take to make a product in this category compared to the base software type, should be between 0 and 1. This scale is also applied to the optimal dev time parameter. |
Retention | How long products keep their interest after release and how long people will use the product in months. Computer operating systems have 72 and Role Playing Games have 24. |
IdealPrice | How much products of this type should ideally cost at 100% quality and interest. This is ignored if the software type already defines it. |
Iterative | How likely AI companies are to develop sequels for this type of software. |
NameGenerator | The name generator to use for simulated companies or for when the player clicks the name button in the design document. |
Name generators
The random name generator uses a tree like structure to generate random strings of words. Generators will be loaded from txt files located in the "NameGenerators" folder and their name will match their file names, minus ".txt". If you name a name generator the same thing as one of the built-in name generators, they will merge their nodes and words, you can use this to expand the words of a built-in name generator.
Writing [REPLACE] as the first line will replace an existing name generator from the game, based on it's file name.
Example
Here is an example of how a name generator can be structured in the text file:
-start(base) -base(base2,end,stop) Hello Hi -base2(end,stop) , you -end(stop) .
This would create a generator that can generate the strings:
- Hello
- Hi
- Hello.
- Hi.
- Hello, you
- Hi, you
- Hello, you.
- Hi, you.
It works by starting from the first node "start" (nodes are the ones with a hyphen in front of the name), it appends a random string from the list of strings below it (in this case there’s nothing to pick), it then picks a random node from the parenthesis of the current node (which can only be "base" in this case), and then it continues until it reaches the node stop. There is a limit to how far it will go, depending on how many nodes there are, to avoid an infinite loop.
Company types
Company types are the types of company that the game will simulate. If you don't define company types for your new software types, the software will not be released by the AI.
Removing companies
You can remove AI company types by adding a "delete.txt" file in the CompanyTypes folder, with a list of the company types you want to remove, separated by new line, eg.
Antivirus Games Office
Values
Specialization | The name/tag of the company type. If you pick a name of one of the built-in company types, you can override it. |
PerYear | The chance of a company of this type being founded every year. All company types in Software Inc. has this set to 0.2, as it seems to work pretty well. |
Min | The minimum amount of companies of this type there has to be on the market at any given point in time. 2 for computer OS, 3 for games. |
Max | The maximum amount of companies of this type there has to be on the market at any given point in time. 2 for computer OS, 6 for games. |
Frameworks | Whether this company will develop frameworks for their products, which can be licensed by the player and other companies. |
Types | The types of products the company will release and how much effort they take(Chance). 1 means they can only work one product of that software type at any given time, 0.25 means they would be able to work on 4 of it at a time. You can define a category for each type, otherwise a random will be chosen from the categories available from the software type. You can also add the record Force True which will make the game force a product out immediately when the game starts, if possible, which is currently used to make sure there is an OS available on day 1. |
NameGen | Optional name generator to use, will use "Company" by default. |
Examples
CompanyType { Specialization "Creative tools" PerYear 0.2 Min 4 Max 8 Types [ { Software "Audio Tool" Chance 1 } { Software "2D Editor" Chance 1 } { Software "3D Editor" Chance 1 } ] }
CompanyType { Specialization "Computer Operating Systems" PerYear 0.2 Min 2 Max 2 Frameworks False Types [ { Software "Operating System" Category Computer Chance 1 Force True } ] }
Personalities
Personalities control employee traits an inter office relationships. All employees have exactly 2 personality traits. All personalities will be merged with the pre-existing personalities in the game.
Elements
PersonalityGraph | This is the root table. If the mod has more than 2 new personalities, you can add a Replace True record to this table, to replace the base personalities of the game. |
Personalities | This list should contain the personalities |
Incompatibilities | This list should contain a list of personalities which cannot be mixed when picking employee personality. |
Personalities and incompatibilities
Personality values include:
Personality | This is the root table |
Name | The personality's name as it appears in the game. |
WorkLearn | Between -1 and 1, where -1 is hard working and 1 is easy learner. |
Social | Between -1 and 1, where -1 is independent and 1 is social. |
LazyStress | Between -1 and 1, where -1 is lazy and 1 is stressed. |
Relationships | This table should contain a list of records, defining how people with this personality feels about another personality, between -1 for bad, 0 for okay and 1 for great. You only need to define this one-way, so if you already have a relationship with Stubborn defined for Short-tempered, you shouldn't also define it other way around. You can define relationships with personalities already in the game. |
The Incompatibilities list should contain a list of personality pairs that are incompatible, meaning they cannot exist in the same person.
Example
PersonalityGraph { Personalities [ { Name TestPersonality WorkLearn 1 Social -1 LazyStress 0.3 Relationships { Extrovert -0.5 TestPersonality2 1 } } { Name TestPersonality2 WorkLearn -0.5 Social 0 LazyStress 0.25 } ] Incompatibilities [ [ TestPersonality; TestPersonality2 ] [ TestPersonality2; Introvert ] ] }