DotP 2014: Best Practices

Due to Duels of the Planeswalkers 2014 not being released yet, these are Best Practices for modding based on what we learned from DotP 2013. This will change once the game is released and we figure out what needs to be done to prevent conflicts and make sure things work well together.

Regarding prefixes and ids we have started a prefix/id registry here (to prevent prefix/id clashing): DotP 2014: Prefix/Id Registry

Packaging Mods

Separate Core & Decks

Best Practice: Keep your Core (cards, card images, functions, etc...) separate from your Decks.

Reasoning: This will allow users to easily manage what decks are visible in game and what cards they have available for building their own decks (either manually or using tools like a deck editor). Not all users will want all decks, but they may want all of the coded cards.

Card Coding

Prefix your Cards

Best Practice: Prefix your created cards (or the multiverse id in the card filename) with a prefix unique to yourself.

Reasoning: Due to the way we anticipate the game will read files, if two or more cards have the same filename the game will pick one (probably the last loaded) to be the one it uses. Since it is possible that two or more modders may make the same card and one may be buggy modders should make sure that their filenames are unique so that they do not override each other (except through mod patches) so that a deck made with a specific card will always use that specific card even if someone else makes the same card it should continue to use the version you intended.

Prefix your Functions and Files

Best Practice: Prefix both your functions and your function files.

Reasoning: Due to the way we anticipate the game reads functions and function files, to prevent conflicts with code from other modders any functions you make should be uniquely prefixed. If you do not prefix your functions then they may be overridden by someone else's mod and the cards in your mod that use that function will cease to work. The same is true of function file names if you create a GENERAL_FUNCTIONS.LOL file and some other modder creates a function file with the same name the two mods will conflict.

If you create a CountSomething() function and another modder creates another function named CountSomething() and the two functions either take different parameters, give different output, or do something different in the function itself then more than likely they will conflict and result in non-working cards. However, if you create a function KFP_CountSomething() and another modder makes a function GT_CountSomething() then they will not conflict.

Prefixing Multiverse Ids

Best Practice: When prefixing Multiverse Ids (with numeric prefixes) you should always include leading zeros to pad the original Multiverse Id up to 6 digits.

Reasoning: Currently there are no Multiverse Ids with more than 6 digits (I've not seen any ids greater than 400,000 yet so we're not likely to hit 7 digits for some time yet), but there are cards with fewer than 6 digits. If someone decides to use a relatively low number prefix to use this could cause issues where the prefixed Multiverse Id could be the non-prefixed Multiverse Id of another card. For example say someone chooses a prefix of 157 and codes Sea Serpent (419) then prefixes the Multiverse Id without leading zeros will give an id of 157419 which is the Multiverse Id of Desecrator Hag instead of a truly unique id like 157000419 (not used). This could also happen with other chosen prefixes so if you prefix Multiverse Ids you should always pad the original Multiverse Id to 6 digits.

Deck Coding

Make Always Available

Best Practice: When creating custom decks they should be made always available using the always_available="true" attribute.

Reasoning: This attribute will unlock the base deck for all users when they first load up the game after the mod has been installed. This should work regardless of how many other decks the user has or what platform they are playing on. If a mod has been loaded up with a deck that does not have this attribute then the deck may be saved to their profile as "Locked" and the user will have to unlock it in some other way.

Put Decks in a Content Pack

Best Practice: When creating custom decks you should put them in a content pack unique to you.

Reasoning: DotP 2014 can only handle 9 decks in content pack 0 (content_pack="0") with the always_available="true" attribute. Decks put into a different content pack do not seem to have this limitation. The reason you should use a content pack unique to you is that the content pack enabling xml that goes in the header should only be used once otherwise you will see a complete set of duplicate decks in the content pack for each time that xml is used.

Example Content Pack Enabling Xml (designed to work for most mods):

<CONTENTPACK UID="<Insert Content Pack Id Here>">
	<PD_SECTION>
		<APP_ID ID="213850" />
	</PD_SECTION>
	<CONTENTFLAGS>
		<AVATAR_CONTENT />
		<DECK_CONTENT />
		<GLOSSARY_CONTENT />
		<UNLOCK_CONTENT />
	</CONTENTFLAGS>
</CONTENTPACK>

Set Platform IDs to be Unlocked by Default

Best Practice: When creating custom decks you should set all the platform ids (*_id_1) to values that will have it fully unlocked by default. Foiling (*_id_2) is purely at the modder's discretion as it is a visual change only.

• Steam
  • steam_id_1="213850"
  • steam_id_2="213850" (Foiling)
• iPad
  • ios_id_1=<Value Currently Unknown>
  • ios_id_2=<Value Currently Unknown> (Foiling)
• Android
  • android_id_1=<Value Currently Unknown>
  • android_id_2=<Value Currently Unknown> (Foiling)

Reasoning: As with 2013 it is likely that the player's profile is a fixed size and thus can only handle so many saved deck configurations. This will allow users to have full access to all the cards in the deck even if the deck is not saved to the profile and thus resets every time the game is closed.