(Feedback) |
(applied the changes proposed by bjorn) |
||
| Line 2: | Line 2: | ||
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. | 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 | 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. | 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. | ||
weapon | |||
:dagger | :dagger | ||
:bow | :bow | ||
| Line 15: | Line 15: | ||
:thrown | :thrown | ||
:wand | :wand | ||
armor | |||
:legs | :legs | ||
:chest | :chest | ||
| Line 25: | Line 25: | ||
:potion | :potion | ||
:food | :food | ||
generic (generic items that can be sold) | |||
Examples: | Examples: | ||
*Sharp knife: <code> | *Sharp knife: <code>weapn-dagger-sharpknive.png</code> | ||
*Cactus drink: <code> | *Cactus drink: <code>use-potion-cactusdrink.png</code> | ||
*Scorpion stinger: <code> | *Scorpion stinger: <code>generic-scorpionstinger.png</code> | ||
== Sourcecode changes == | == 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. | 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:51, 17 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.
weapon
- dagger
- bow
- arrow
- sword
- polearm
- axe
- thrown
- wand
armor
- legs
- chest
- feet
- head
- hands
- shield
use (items that can be used)
- potion
- food
generic (generic items that can be sold)
Examples:
- Sharp knife:
weapn-dagger-sharpknive.png - Cactus drink:
use-potion-cactusdrink.png - Scorpion stinger:
generic-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.
