(→Sourcecode changes: i tried around and found another method of implementation to bu much better) |
|||
Line 34: | Line 34: | ||
== Sourcecode changes == | == Sourcecode changes == | ||
The necessary changes at the sourcecode are marginal. The | The necessary changes at the sourcecode are marginal. The ItemInfo class will be created with a filename instead of an itemId and the getImage method will return a pointer to an image (optained from the resource manager when called) instead of an integer. This also simplifies the code of the calling procedures because they don't have to optain the image from the spriteset but can use the return value from ItemInfo::getImage() directly. |
Revision as of 15:38, 10 August 2006
This article is currently only a proposal
The features or design guidelines described in this article are only a proposal made by one or some persons. It has not been evaluated or accepted by the core development team yet. Feel free to add your personal opinion about them or make counter proposals.
On IRC we had the idea to split up the item spriteset into single images to make changes and additions easier. The items.xml file will then map to the filenames of the item icons and no longer to the indexes on the spriteset.
As naming conventions i propose maincategory_subcategory_itemname(in one word).png. The subcategory is optional.
These are the main categories and the subcategories in them that i propose. I added only those that are necessary to categorize the items that are in the current item spriteset. Later additions might make new categories and subcategories necessary.
wpn (weapon)
- dagger
- bow
- arrow
- sword
- polearm
- axe
- thrown
- wand
arm (armor)
- legs
- chest
- feet
- head
- hands
- shield
use (items that can be used)
- potion
- food
gen (generic items that can be sold)
Examples:
- Sharp knife: wpn_dagger_sharpknive.png
- Cactus drink: use_potion_cactusdrink.png
- Scorpion stinger: gen_scorpionstinger.png
Sourcecode changes
The necessary changes at the sourcecode are marginal. The ItemInfo class will be created with a filename instead of an itemId and the getImage method will return a pointer to an image (optained from the resource manager when called) instead of an integer. This also simplifies the code of the calling procedures because they don't have to optain the image from the spriteset but can use the return value from ItemInfo::getImage() directly.