Difference between revisions of "Modding"

From Software Inc.
Jump to navigation Jump to search
(29 intermediate revisions by the same user not shown)
Line 1: Line 1:
{|class="wikitable"
+
Mods in Software Inc. can be defined in simple text-based files or using C# and compiling code for the game to load. You can add new software types, furniture, translations and room textures using only the [[TyD|TyD]] file format.  
|style="font-size:125%" | [[Furniture Modding]] is a separate page
 
|}
 
{|class="wikitable"
 
|style="font-size:125%" | [[Material Modding]] is a separate page
 
|}
 
{|class="wikitable"
 
|style="font-size:125%" | [[Code Modding]] is a separate page
 
|}
 
Modding in Software Inc. is completely data driven. Software Inc. loads [[TyD|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: "[[Modding#Company types|CompanyTypes]]", "[[Modding#Name generators|NameGenerators]]" and "[[Modding#Software types|SoftwareTypes]]".
 
 
 
The root of your mod can additionally include a Personalities.tyd file to add new [[Modding#Personalities|personalities]] to the game.
 
  
 
== Debugging console ==
 
== Debugging console ==
The debugging console is enabled by binding the console key at the bottom of the key binding menu in the options window.
+
You'll need the in-game console to properly test your mods and check if everything is working as it should. The debugging console is enabled by binding the console key at the bottom of the key binding menu in the options window.
  
===Helpful commands===
+
== Folder structure ==
* '''INSTA_DEVELOP_DESIGN''' - Instantly releases whatever is in the design document window, skipping design and dev phases (Only works for modded software)
+
Unless downloaded from the Steam Workshop, mods are placed in the root of the game folder, depending on which type of mod your are making. Each mod should be placed in its own folder within the following folders (Note that these folders might not exist in the first place, so you should create them yourself):
* '''RELOAD_MOD''' X - Reloads mod named X. Note that this does not affect the currently running game, if there is any
+
* Software types and personalities should be placed in the '''Mods''' folder.
* '''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
+
* Furniture should be placed in the '''Furniture''' folder.
* '''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
+
* Room, path and roof textures should be placed in the '''Materials''' folder.
* '''LIST_SCOPE_MEMBERS''' X - Prints out all functions and variables available for the type X, to use when making level 3 feature scripts
+
* C# code and dll files should be placed in the '''DLLMods''' folder.
* '''COMPARE_LOCALIZATION''' X Y - Compares what has changed between between localization X and Y, Y should almost always be "English"
+
* Translations should be placed in the '''Localization''' folder.
* '''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 ==
+
== Meta file ==
These are zip files of the software types, company types, name generators and personality types currently in the game:
+
Each mod will take its name from the folder it is in. However, you can customize the '''Name''', '''Description''' and '''Author''' of your mod by adding a meta.tyd file to the root of your mod's folder, containing the specified records. This file will be created automatically when you edit your mod in-game (Not implemented yet as of Alpha 11.4.7).
  
[http://softwareinc.coredumping.com/wiki/Resources.zip Alpha 8.6.1 data - 23 KB]
+
== Localizations ==
 +
All mods can have their own custom localizations defined, to make it easier to translate, or support multiple languages out of the box. Simply add a '''Localization''' folder to the root of your mod's folder, and then put a folder with the name of each language you want to translate to, which should at minimum contain '''English'''. Translations are just a list of [[TyD|TyD]] records, however software types and features are a little more complex, and you should follow the layout in the '''Software.Tyd''' file in the main English localization folder. Your translations will be loaded and used based on the name of the language the player is currently using.
  
[http://softwareinc.coredumping.com/wiki/Alpha9Data.zip Alpha 9.7.6 data - 35 KB]
+
== Mod types ==
 +
=== Data mod ===
 +
[[Data Modding|Read the documentation here.]]
  
[http://softwareinc.coredumping.com/wiki/Alpha10Data.zip Alpha 10.1.4 data - 23 KB]
+
Data mods can add, change or remove software types, AI company types, name generators and employee personalities. This is all done with [[TyD|TyD]] files, however software can have scripts attached using [[SIPL|SIPL]].
  
[http://softwareinc.coredumping.com/wiki/Alpha11Data.zip Alpha 11.4.1 data - 22 KB]
+
=== Furniture ===
 +
[[Furniture Modding|Read the documentation here.]]
  
== Alpha 11 changes ==
+
You can add furniture using .obj 3D object files. The furniture modding system, while only using [[TyD|TyD]] files, allows you to change pretty much anything about your furniture that would be possible to change from within the game's engine.
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 ===
+
=== Materials ===
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.
+
[[Material Modding|Read the documentation here.]]
  
=== Why? ===
+
Material mods allow you to load textures into the game for interior walls, exterior walls, floors, roofs and paths.
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 ===
+
=== Code mod ===
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 doesn'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.
+
[[Code Modding|Read the documentation here.]]
  
== Software types ==
+
If you want to dive even further, you can put .cs files directly with the game, and it will compile and load your scripts on startup. For more control you can compile your own DLL files for the game to load.
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|TyD]] file in the "SoftwareTypes" folder.
 
  
=== Overview ===
+
=== Localizations ===
<div style="display:table">
+
To create a localization you can copy the English folder from the Localization folder and fill in your own text in the appropriate fields. Localization files are written entirely in [[TyD|TyD]], to be easily human readable.
[[File:SoftwareTypeOverview.png|frame|The elements of a software mod]]
 
  
[[File:SoftwareTypeOverviewInGame.png|frame|Same elements as represented in-game]]</div>
+
Localizations can also contain '''femalefirstnames.txt''', '''malefirstnames.txt''' and '''lastnames.txt''' files to overwrite the default employee names in the game. These should contain a list of names separated by new lines, ordered by how common the name is.
  
=== Elements ===
+
====Helpful console commands====
A software type TyD table should contain the following elements:
+
* '''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
{|class="wikitable"
+
* '''RELOAD_LOCALIZATION''' - Reloads all localizations, but does not update UI instantly when in-game
|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 [[Modding#Software categories|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 [[Modding#Name generators|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 [[Modding#Features|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''' <span style="color:blue">"Test Software"</span>
 
'''Category''' <span style="color:blue">Testing</span>
 
'''Description''' <span style="color:blue">"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."</span>
 
'''Random''' <span style="color:blue">0.1</span>
 
'''IdealPrice''' <span style="color:blue">50</span>
 
'''OptimalDevTime''' <span style="color:blue">25</span>
 
'''OSSupport''' <span style="color:blue">Computer</span>
 
'''OneClient''' <span style="color:blue">False</span>
 
'''InHouse''' <span style="color:blue">False</span>
 
'''SubmarketNames''' [ <span style="color:blue">TestMarket1</span>; <span style="color:blue">TestMarket2</span>; <span style="color:blue">TestMarket3</span> ]
 
'''Categories'''
 
[
 
{
 
'''Name''' <span style="color:blue">"Test category"</span>
 
'''Description''' <span style="color:blue">"This is a test category"</span>
 
'''Popularity''' <span style="color:blue">0.5</span>
 
'''Submarkets''' [ <span style="color:blue">1;</span> <span style="color:blue">3</span>; <span style="color:blue">1</span> ]<span style="color:green">#20%, 60%, 20%</span>
 
'''Retention''' <span style="color:blue">24</span>
 
'''TimeScale''' <span style="color:blue">1</span>
 
'''Iterative''' <span style="color:blue">0.75</span>
 
'''NameGenerator''' <span style="color:blue">testgen</span>
 
}
 
]
 
'''Features'''
 
[
 
{
 
'''Name''' <span style="color:blue">"Test feat 1"</span>
 
'''Spec''' <span style="color:blue">System</span>
 
'''Description''' <span style="color:blue">"This feature represents the system aspect of the product and cannot be deselected"</span>
 
'''DevTime''' <span style="color:blue">3</span>
 
'''CodeArt''' <span style="color:blue">1</span>
 
'''Submarkets''' [ <span style="color:blue">1;</span> <span style="color:blue">0</span>; <span style="color:blue">1</span> ]<span style="color:green">#50%, 0%, 50%</span>
 
'''Features'''
 
[
 
{
 
'''Name''' <span style="color:blue">"Test subfeat 1"</span>
 
'''Description''' <span style="color:blue">"This feature requires a level 1 System designer/programmer to be finished"</span>
 
'''DevTime''' <span style="color:blue">3</span>
 
'''Level''' <span style="color:blue">1</span>
 
'''CodeArt''' <span style="color:blue">1</span>
 
'''Submarkets''' [ <span style="color:blue">0</span>; <span style="color:blue">1</span>; <span style="color:blue">0</span> ]
 
}
 
{
 
'''Name''' <span style="color:blue">"Test subfeat 2"</span>
 
'''Description''' <span style="color:blue">"This feature will cost the owner $1000 per day when it is released"</span>
 
'''DevTime''' <span style="color:blue">2</span>
 
'''Level''' <span style="color:blue">3</span>
 
'''CodeArt''' <span style="color:blue">1</span>
 
'''Submarkets''' <span style="color:blue">0</span> <span style="color:green">#No submarkets needed for level 3 features</span>
 
'''Script_EndOfDay''' <span style="color:blue">"Product.DevCompany.MakeTransaction(-1000, Bills, \"Owned\");"</span>
 
}
 
]
 
}
 
{
 
'''Name''' <span style="color:blue">"Test feat 2"</span>
 
'''Spec''' <span style="color:blue">Audio</span>
 
'''Dependencies''' <span style="color:blue">"Audio Tool"</span>
 
'''Optional''' <span style="color:blue">True</span>
 
'''Description''' <span style="color:blue">"This feature can be deselected, completely removing Audio features and Audio Tool dependencies from the product"</span>
 
'''DevTime''' <span style="color:blue">4</span>
 
'''CodeArt''' <span style="color:blue">1</span>
 
'''Submarkets''' [ <span style="color:blue">0</span>; <span style="color:blue">1</span>; <span style="color:blue">3</span> ]<span style="color:green">#0%, 25%, 75%</span>
 
}
 
]
 
}
 
 
 
=== 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 ([[Modding#SubFeatures|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 ====
 
 
 
{|class="wikitable"
 
|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 ====
 
{|class="wikitable"
 
|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. [[Modding#Level 3 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. [[SIPL|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:
 
{|class="wikitable"
 
|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|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(<span style="color:blue">"MicMining"</span>, <span style="color:blue">true</span>)) <span style="color:green">//Check if player has been caught</span>
 
{
 
Product.Bugs = Max(<span style="color:blue">0</span>, Product.Bugs - Product.Userbase * <span style="color:blue">0.01</span>); <span style="color:green">//Remove 1 bug from product for each 100th active user</span>
 
'''if''' (Random() * Product.Userbase > <span style="color:blue">1000000</span> * Product.Category.Popularity)  <span style="color:green">//Random chance of getting caught</span>
 
{
 
LaunchLawsuit(<span style="color:blue">"SpyingOnUsers"</span>, Product.Sum, <span style="color:blue">1</span>);  <span style="color:green">//Create anonymous lawsuit</span>
 
Product.DevCompany.AddFans(-Product.Userbase, Product.Category);  <span style="color:green">//Remove fans and market recognition from player in category</span>
 
Product.Userbase = Product.Userbase * <span style="color:blue">0.05</span>;  <span style="color:green">//Remove 95% of active users</span>
 
Product.KillAwareness();  <span style="color:green">//Remove all marketing</span>
 
Product.PutVar(<span style="color:blue">"MicMining"</span>, <span style="color:blue">false</span>);  <span style="color:green">//Mark player as caught for this product</span>
 
}
 
}
 
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 ====
 
{|class="wikitable"
 
|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 [[Modding#Name generators|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:
 
 
 
<pre>-start(base)
 
-base(base2,end,stop)
 
Hello
 
Hi
 
-base2(end,stop)
 
, you
 
-end(stop)
 
.</pre>
 
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 ==
 
'''THIS SECTION IS NOT UPDATED TO ALPHA 11 YET!'''
 
 
 
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.xml" file in the CompanyTypes folder, which includes a root tag containing a tags with the company types you want to remove, eg.
 
 
 
<pre>
 
<CompanyTypes>
 
<Type>Web CMS</Type>
 
<Type>Financial CMS</Type>
 
<Type>Workflow CMS</Type>
 
</CompanyTypes>
 
</pre>
 
 
 
=== Tags ===
 
 
 
{|class="wikitable"
 
|CompanyType
 
|This is the root tag, which all tags should be a child to.
 
|-
 
|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. Note that this only works for Alpha 4.5+
 
|-
 
|Force
 
|Whether a company of this type should be created on the first day and be forced to launch software on the first day. It is currently only used to launch a Computer Operating System on day one: <Force>Operating System,Computer</Force>. Just omit the tag if you don't need 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. 1 for computer OS, 2 for games.
 
|-
 
|Max
 
|The maximum amount of companies of this type there has to be on the market at any given point in time. 3 for computer OS, 6 for games.
 
|-
 
|Types
 
|The types of products the company will release and how much effort they take. 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. Currently this is set to 1 for all company types in Software Inc. as going lower seems to spam the market. You can define a category for each type, otherwise a random will be chosen from the categories available from the software type.
 
|-
 
|NameGen
 
|Optional name generator to use, will use "Company" by default. Only available in alpha 9.7+
 
|}
 
 
 
=== Examples ===
 
<pre><CompanyType>
 
<Specialization>Tools</Specialization>
 
<PerYear>0.2</PerYear>
 
<Min>1</Min>
 
<Max>4</Max>
 
<Types>
 
<Type Software="Audio Tool">1</Type>
 
<Type Software="Visual Tool">1</Type>
 
<Type Software="Antivirus">1</Type>
 
</Types>
 
</CompanyType></pre>
 
 
 
<pre><CompanyType>
 
<Specialization>Computer Operating Systems</Specialization>
 
<Force>Operating System,Computer</Force>
 
<PerYear>0.2</PerYear>
 
<Min>1</Min>
 
<Max>3</Max>
 
<Types>
 
<Type Software="Operating System" Category="Computer">1</Type>
 
</Types>
 
</CompanyType></pre>
 
 
 
== 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 ===
 
{|class="wikitable"
 
|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:
 
{|class="wikitable"
 
|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 ===
 
<pre>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 ]
 
]
 
}</pre>
 

Revision as of 12:08, 7 April 2020

Mods in Software Inc. can be defined in simple text-based files or using C# and compiling code for the game to load. You can add new software types, furniture, translations and room textures using only the TyD file format.

Debugging console

You'll need the in-game console to properly test your mods and check if everything is working as it should. The debugging console is enabled by binding the console key at the bottom of the key binding menu in the options window.

Folder structure

Unless downloaded from the Steam Workshop, mods are placed in the root of the game folder, depending on which type of mod your are making. Each mod should be placed in its own folder within the following folders (Note that these folders might not exist in the first place, so you should create them yourself):

  • Software types and personalities should be placed in the Mods folder.
  • Furniture should be placed in the Furniture folder.
  • Room, path and roof textures should be placed in the Materials folder.
  • C# code and dll files should be placed in the DLLMods folder.
  • Translations should be placed in the Localization folder.

Meta file

Each mod will take its name from the folder it is in. However, you can customize the Name, Description and Author of your mod by adding a meta.tyd file to the root of your mod's folder, containing the specified records. This file will be created automatically when you edit your mod in-game (Not implemented yet as of Alpha 11.4.7).

Localizations

All mods can have their own custom localizations defined, to make it easier to translate, or support multiple languages out of the box. Simply add a Localization folder to the root of your mod's folder, and then put a folder with the name of each language you want to translate to, which should at minimum contain English. Translations are just a list of TyD records, however software types and features are a little more complex, and you should follow the layout in the Software.Tyd file in the main English localization folder. Your translations will be loaded and used based on the name of the language the player is currently using.

Mod types

Data mod

Read the documentation here.

Data mods can add, change or remove software types, AI company types, name generators and employee personalities. This is all done with TyD files, however software can have scripts attached using SIPL.

Furniture

Read the documentation here.

You can add furniture using .obj 3D object files. The furniture modding system, while only using TyD files, allows you to change pretty much anything about your furniture that would be possible to change from within the game's engine.

Materials

Read the documentation here.

Material mods allow you to load textures into the game for interior walls, exterior walls, floors, roofs and paths.

Code mod

Read the documentation here.

If you want to dive even further, you can put .cs files directly with the game, and it will compile and load your scripts on startup. For more control you can compile your own DLL files for the game to load.

Localizations

To create a localization you can copy the English folder from the Localization folder and fill in your own text in the appropriate fields. Localization files are written entirely in TyD, to be easily human readable.

Localizations can also contain femalefirstnames.txt, malefirstnames.txt and lastnames.txt files to overwrite the default employee names in the game. These should contain a list of names separated by new lines, ordered by how common the name is.

Helpful console commands

  • 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