(→Sourcecode changes: i tried around and found another method of implementation to bu much better) |
(Feedback) |
||
| Line 29: | Line 29: | ||
Examples: | Examples: | ||
*Sharp knife: wpn_dagger_sharpknive.png | *Sharp knife: <code>wpn_dagger_sharpknive.png</code> | ||
*Cactus drink: use_potion_cactusdrink.png | *Cactus drink: <code>use_potion_cactusdrink.png</code> | ||
*Scorpion stinger: gen_scorpionstinger.png | *Scorpion stinger: <code>gen_scorpionstinger.png</code> | ||
:''As I pointed out on IRC I'd like to see two changes. To use dashes instead of underscores for separating words, and to use full names instead of the short versions 'wpn' and 'arm'. The examples would thus become: <code>weapon-dagger-sharpknive.png</code>, <code>usable-potion-cactusdrink.png</code> and <code>generic-scorpionstinger.png</code>. As such the naming scheme would have my approval. --[[User:Bjørn|Bjørn]] 23:53, 12 August 2006 (CEST) | |||
== 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. | ||
:''This implementation sounds fine to me.'' --[[User:Bjørn|Bjørn]] 23:53, 12 August 2006 (CEST) | |||
Revision as of 21:53, 12 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
- As I pointed out on IRC I'd like to see two changes. To use dashes instead of underscores for separating words, and to use full names instead of the short versions 'wpn' and 'arm'. The examples would thus become:
weapon-dagger-sharpknive.png,usable-potion-cactusdrink.pngandgeneric-scorpionstinger.png. As such the naming scheme would have my approval. --Bjørn 23:53, 12 August 2006 (CEST)
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.
- This implementation sounds fine to me. --Bjørn 23:53, 12 August 2006 (CEST)
