Modding

From Software Inc.
Revision as of 02:02, 15 January 2016 by Khornel (talk | contribs) (→‎Scenarios)
Jump to navigation Jump to search

Modding in Software Inc. is completely data driven. Software Inc. loads XML 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: "Companies", "CompanyTypes", "Events", "NameGenerators", "Scenarios" and "SoftwareTypes".

The root of your mod can additionally include a Personalities.xml file to add new personalities to the game.

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 XML file in the "SoftwareTypes" folder.

Tags

A software type XML file should contain the following tags:

SoftwareType This is the root tag, which all tags should be a child to. If this tag has the attribute Override="True", all tags 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 tag, you will delete all features from the software type.
Name The name of the software as it will appear in dropdown lists, etc.
Delete Optional tag which deletes the software type from the game, if it is set to TRUE
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. Can be omitted.
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</Unlock>
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.
Popularity How popular a software type is, which limits the maximum amount of income. Computer operating systems have 1 and Role Playing Games have 0.6. (Ignored if software type has categories defined)
Retention How long people will use the product, should be between 0 and 1, not including 1. Computer operating systems have 0.9 and Role Playing Games have 0.7. (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)
OSSpecific Whether you need to choose an operating system for this software.
OneClient Whether this software is for contract work. This does not currently work as expected, so you should probably avoid setting this to TRUE.
InHouse Whether you can lock this software to your own company. This makes sense for game engines, but not for 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)
Needs All software types that this software type depends on, each need should be defined in a <Name> tag in the <Needs> tag. This will be deprecated at some point in the future and decided by feature dependencies instead.
Features All features that this software can implement.

Example

<SoftwareType>
	<Name>Test Software</Name>
	<Category>Testing</Category>
	<Description>This is part of a test mod. If you develop a perfect version, 50% of the population will want it, but 10% might randomly not want it.</Description>
	<Random>0.1</Random>
	<Categories>
		<Category Name="Test category">
			<Description>This is a test category</Description>
			<Popularity>0.5</Popularity>
			<Retention>0.5</Retention>
			<TimeScale>1</TimeScale>
			<Iterative>0.75</Iterative>
			<NameGenerator>testgen</NameGenerator>
		</Category>
	</Categories>
	<OSSpecific>TRUE</OSSpecific>
	<OneClient>FALSE</OneClient>
	<InHouse>FALSE</InHouse>
	<Needs>
		<Name>Visual Tool</Name>
	</Needs>
	<Features>
		<Feature Forced="TRUE">
			<Name>Test feat 1</Name>
			<Description>This feature will always be selected unless superseded by a feature with this as "From".</Description>
			<DevTime>2</DevTime>
			<Innovation>0</Innovation>
			<Usability>1</Usability>
			<Stability>1</Stability>
			<CodeArt>1</CodeArt>
			<Dependencies></Dependencies>
		</Feature>
		<Feature From="Test feat 1">
			<Name>Test feat 2</Name>
			<Description>This feature takes 6 months to make and has 4/6 Usability.</Description>
			<DevTime>6</DevTime>
			<Innovation>1</Innovation>
			<Usability>4</Usability>
			<Stability>1</Stability>
			<CodeArt>1</CodeArt>
			<Dependencies>
				<Dependency Software="Visual Tool">Image viewing</Dependency>
			</Dependencies>
		</Feature>
		<Feature>
			<Name>Test feat 3</Name>
			<Description>This feature takes just as many artists as programmers and offers no stability.</Description>
			<DevTime>5</DevTime>
			<Innovation>1</Innovation>
			<Usability>1</Usability>
			<Stability>0</Stability>
			<CodeArt>0.5</CodeArt>
			<Dependencies>
				<Dependency Software="Test Software">Test feat 2</Dependency>
			</Dependencies>
		</Feature>
	</Features>
</SoftwareType>

Features

Features are defined in the Feature tag of Software types. Optinally a base.xml file can be placed in the "SoftwareTypes" folder with feature definitions, which will then be added to all software. If the root tag of the base.xml file contains the attribute Override = "TRUE", it will remove any base features already defined, this would remove the built-in QA feature for example.

Tags

Feature This is the root tag, which all tags should be a child to. If this tag has the attribute Forced = "TRUE", then this will be implemented by default and the player won't be able to un-tick it, unless it is superseded by another feature. If this tag has the From = "FeatureName" tag, this feature will supersede the feature called "FeatureName", and you can then build entire dependency trees like this. You can also use the Vital="TRUE" attribute to make AI companies prioritize this feature and make customers expect it, e.g. the 3D feature for operating systems is vital, since you wouldn't expect an operating system to not have it after it has been invented and used, it is however scope based, so it is still okay for small to medium size operating systems to not have 3D, e.g. operating systems for smart phones.
Name The name of the feature as it will appear in feature panel in the design document window
Category An optional tag that controls which specialization a product belongs to. If it is omitted the feature will belong to the base skill level of a field, usually described as "General" in Software Inc. which is controlled by the employees main skill in a role. Otherwise the employees specialization skill will control how well, if at all, they work with this feature. This can be 2D, 3D, Network, etc. You can add new specializations to the game using this tag.
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</Unlock>. Specializations will unlock, when the first feature which uses it unlocks.
DevTime How many months it takes to develop this feature
Innovation, Usability, Stability These three tags are normalized, so you can put in any number. 3, 4 and 5 would result in 3/12, 4/12 and 5/12. Innovation controls how long the product will stay interesting to customers. Usability controls how well customers will like the product and in extension, your company. Stability controls bugs and how much skill your employees will gain from working on the feature.
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.
Server A value indicating how much server hosting power this feature requires. It is scaled with DevTime and popularity, so it should probably be somewhere between 0 and 1.
Dependencies What features this feature depends on to be available, this can be features in the current product, features in other products or features in supported operating system. Note that opretaing system feature dependencies are taken as an intersection, so if a features relies on 3D in an operating system, ALL chosen operating systems must support 3D. A dependency should be defined as <Dependency Software="Operating System">3D</Dependency>

Software categories

Software categories are defined in the Categories tag of the software type XML file. 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.

Tags

Category Name="X" This is the root tag, which all tags should be a child to. Use the name attribute to give the category a name.
Description
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.
TimeScale How it will take to make a product in this category compared to the base software type, should be between 0 and 1.
Retention How long people will use the product, should be between 0 and 1, not including 1. Computer operating systems have 0.9 and Role Playing Games have 0.7.
Iterative How likely AI companies are to develop sequels for this type of software. (Ignored if software type has categories defined)
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.

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:

  1. Hello
  2. Hi
  3. Hello.
  4. Hi.
  5. Hello, you
  6. Hi, you
  7. Hello, you.
  8. 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.

Tags

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 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.

Examples

<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>
<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>

Scenarios

Scenarios can define the start conditions, goals and events in-game. A scenario type XML file should contain the following tags:

Scenario This is the root tag, which all tags should be a child to.
Money The available amount of money at the game start. Easy defined like this: 
<Amount>1000</Amount>
Goals Goals define the "win" condition/s. You define goals by putting first the needed Money and then the date when the money has to be reached in. You have to do it like this: 
<Goal>Money 200000,Date 6-1980</Goal>
or 
<Goal>Money 2000000,Date 4-1988</Goal>
Years The available start years at the start of a new game. E.g.: 
<Year>1976</Year>
Events Events are differently made XML Files in the "Events" Folder. View Events for more info (currently no info there). E.g.: 
<Event>Test</Event>
// Replace "Test" with the name of your XML File
Simulation Nothing here yet, sorry

Example of a "scenario" file: 

<Scenario>
	<Name>Test scenario</Name>
	<Money>
		<Amount>500</Amount>
		<Amount>1000</Amount>
	</Money>
	<Goals>
		<Goal>Money 1337,Date 5-1995</Goal>
		<Goal>Money 1000000,Date 5-2012</Goal>
	</Goals>
	<Years>
		<Year>1980</Year>
		<Year>1985</Year>
                <Year>2023</Year>
	</Years>
	<Events>
		<Event>Test</Event>
	</Events>
	<Simulation>TRUE</Simulation>
</Scenario>

Events

Nothing here yet

Companies

Nothing here yet

Personalities

Nothing here yet

Retrieved from "https://softwareinc.coredumping.com/wiki/index.php?title=Modding&oldid=276"