The vendor screen is nice for buyback. And serves as a reminder to sell anything that's been taking up space in the inventory.
It would be easy to add an instant-sell penalty (e.g. instant-sell gives 10%, vendors give 20%). We'll see. I think it's a bad idea to even add the option. If a gamer has to stop and consider whether to instantly sell or hold onto an unusable item, I'd feel like I failed as a game designer.
Hoarding items to drag back to the vendor isn't a fun mechanic. But seeing new loot drop is a bit addicting, even if it's trash. (Arguably this is bad design; addicting is not the same as genuine fun).
Dropping auto gold isn't a terrible idea, but I rather the player make that decision.
Embraaaace the magic sell-anywhere mechanic. I will make an engine option to toggle it though.
Notice the side wall of the stairs (the brown part). It's mostly a flat polygon with a texture applied, plus several "bricks" that stick out randomly with the same texture. The bricks are just scaled cubes with the backface removed, and placed right next to the wall. Make each brick a different thickness (out from the wall) to get a good feel. Minimal effort for a nice result.
Hm, Poser. Are his human figures based on the Daz3D default people (are they still called Michael and Victoria?). If so, that may reduce the usefulness of those assets for OpenGameArt.
Similar issue with all the textures, if they're sourced from places like cgtextures then the assets are near useless to OGA.
You've missed a point -- the size of the png files is irrelevant. Once it's in memory it has to be completely uncompressed to be useful. It's going to be 32 bits per pixel in memory no matter what you do with the png files.
It only uses the images it needs, correct. But on a given map it needs the hero, any creature on the map, and the map's tile set.
Reminder, it's held in memory uncompressed (32 bits per pixel). The file sizes you see for the .png files are highly compressed. Try converting the png files to BMP to get an idea of how much space they take up in memory.
If you want to render larger versions of Flare art, in Blender just change the render size (keeping the same aspect ratio). In the Properties window, the Render tab has a widget named "Dimensions". You should see the X,Y resolution there.
A few warnings:
Some of the art is not set up for easy one-click rendering. Some of the character and spell art has a python script to rotate and render the scene, so Run Script is used to render all the frames. Some tile set pieces have animations instead, so the Animate button is used to render all the frames. But sometimes it takes manipulaing the scene between each render (often rotating and moving objects; in rare cases, changing textures or scene options).
Storing very large images like that will take up more memory than you think. Currently Flare takes up about 100MB at runtime for images; if you scale up to 512x256 (8x) it would require 64x more memory (remember, that's 8x in both dimensions), over 6GB of video RAM. I'm not sure if video cards even go that high yet? Some video cards may not even hold images above a certain size. Map loading will be quite slow. etc.
Finally, most of Flare's older art isn't designed to look good at larger sizes. It's going to be ugly at 512x256.
The vendor screen is nice for buyback. And serves as a reminder to sell anything that's been taking up space in the inventory.
It would be easy to add an instant-sell penalty (e.g. instant-sell gives 10%, vendors give 20%). We'll see. I think it's a bad idea to even add the option. If a gamer has to stop and consider whether to instantly sell or hold onto an unusable item, I'd feel like I failed as a game designer.
Hoarding items to drag back to the vendor isn't a fun mechanic. But seeing new loot drop is a bit addicting, even if it's trash. (Arguably this is bad design; addicting is not the same as genuine fun).
Dropping auto gold isn't a terrible idea, but I rather the player make that decision.
Embraaaace the magic sell-anywhere mechanic. I will make an engine option to toggle it though.
Made a slight modification. Added chains to the downstairs model to emphasize the dungeon theme.
Attention lazy 3D modelers (like me) --
Notice the side wall of the stairs (the brown part). It's mostly a flat polygon with a texture applied, plus several "bricks" that stick out randomly with the same texture. The bricks are just scaled cubes with the backface removed, and placed right next to the wall. Make each brick a different thickness (out from the wall) to get a good feel. Minimal effort for a nice result.
(edit)
See more thoughts in this model here: http://flarerpg.org/blog/20120910
Ooh I like this quite a lot. I may be using this armor design in my next game.
Hm, Poser. Are his human figures based on the Daz3D default people (are they still called Michael and Victoria?). If so, that may reduce the usefulness of those assets for OpenGameArt.
Similar issue with all the textures, if they're sourced from places like cgtextures then the assets are near useless to OGA.
You've missed a point -- the size of the png files is irrelevant. Once it's in memory it has to be completely uncompressed to be useful. It's going to be 32 bits per pixel in memory no matter what you do with the png files.
It only uses the images it needs, correct. But on a given map it needs the hero, any creature on the map, and the map's tile set.
Reminder, it's held in memory uncompressed (32 bits per pixel). The file sizes you see for the .png files are highly compressed. Try converting the png files to BMP to get an idea of how much space they take up in memory.
If you want to render larger versions of Flare art, in Blender just change the render size (keeping the same aspect ratio). In the Properties window, the Render tab has a widget named "Dimensions". You should see the X,Y resolution there.
A few warnings:
Some of the art is not set up for easy one-click rendering. Some of the character and spell art has a python script to rotate and render the scene, so Run Script is used to render all the frames. Some tile set pieces have animations instead, so the Animate button is used to render all the frames. But sometimes it takes manipulaing the scene between each render (often rotating and moving objects; in rare cases, changing textures or scene options).
Storing very large images like that will take up more memory than you think. Currently Flare takes up about 100MB at runtime for images; if you scale up to 512x256 (8x) it would require 64x more memory (remember, that's 8x in both dimensions), over 6GB of video RAM. I'm not sure if video cards even go that high yet? Some video cards may not even hold images above a certain size. Map loading will be quite slow. etc.
Finally, most of Flare's older art isn't designed to look good at larger sizes. It's going to be ugly at 512x256.
What operating system are you playing on? In many unix-like operating systems your personal settings will be here:
~/.config/flare/settings.txt
Where ~ means your home folder.
If you're on Windows or other non-unix operating systems, there is a "config" folder created inside the flare folder.
Pages