We haven't really decided the way to go with the core engine. It comes down to some game design choices. Some games have a Physical damage type, some games have Blunt/Slashing/Piercing subtypes.
Right now Armor Absorption is a flat # reduction while Resistance is a % reduction. Where to put Physical damage (absorption, resistance, both?) it's hard to say.
So physical vs. elemental damage, flat reduction vs. % reduction, there are lots of combinations. I'm not sure which the engine should handle, or the best way to make it generic.
Further, whether to treat these reductions as a fixed value or have diminishing returns. Maybe 100 resistance reduces incoming damage by 50%, but 200 resistance reduces damage by 75%. 300 resist for 87.5%. etc. Maybe the level difference betwen the attacker and defender adds in to the formula. Maybe the attacker can have a Piercing stat that ignores some amount of resistance.
At any rate, instead of making a very convoluted system to handle all cases, maybe it's best to isolate these calculations into a calculations class. Then at least someone changing the engine would have to do so in one place.
3. Set the enemy txt file to attunement_fire=0. That will multiply fire damage by 0. (default = 100, which is interpreted as 100%, so it multiplies damage by 1). So to take double damage from fire you'd say attunement_fire=200
"The authors of this content agree to license it under later versions of the licenses they selected above."
This means that the original artist has agreed to allow future versions of the specified licenses. For instance, Creative Commons licenses are version 3.0, but 4.0 will be the standard one day (and 5.0, etc). This is our way of saying the artist has already accepted future versions of this license.
You as the user of this art are still free to choose any one license.
There are new .pot files that contain the up-to-date strings.
If you have a .po editing tool, it should allow you to merge those new strings into the *de.po files. Unfortunately I'm not very familiar with those tools. Let me see if I can get someone else to chime in on this.
The file name prefixes help there somewhat. All the Menus, Widgets, and GameStates are grouped together, and most of the remaining files are harder to categorize.
Thanks! I'm not really sure if the way my game is done is typical, but it seems to be easy to follow. In the end, as long as it works (the players won't care) and it's easy to maintain/update, it's good enough.
Maybe I can do a timelapse or tutorial one day about making Flare assets. Besides the camera position and output scripting, actually creating the models is mundane -- any Blender tutorial will be helpful there. Sometimes I get textures from OGA, sometimes I use some Public Domain sources (like the Blender Texture CD).
I imagine Diablo has a base MapGenerator interface and several derived classes for each major map type. Random map generation can be done in many ways. You might create rooms first, then connect them with hallways. You might use a Maze generating algorithm. You might create rooms, then enlarge them until they overlap with another room. You might have a few prebuilt chunks that you combine in a few random combinations. Or some weird combination of algorithms. I'm sure one day Flare will support random maps, but I don't yet know what method we'll use. I'll need to study up on existing algorithms.
makrohn, not sure how long it takes to process for the Ubuntu Software Center. There are other fine folks that handle that for me.
torch, it might be a permissions issue? It may be trying to read/write your home directory in two places:
~/.config/flare/
~/.local/share/flare/
by default; if you have some environment variables set (e.g. XDG stuff) it might be trying to I/O different locations.
We haven't really decided the way to go with the core engine. It comes down to some game design choices. Some games have a Physical damage type, some games have Blunt/Slashing/Piercing subtypes.
Right now Armor Absorption is a flat # reduction while Resistance is a % reduction. Where to put Physical damage (absorption, resistance, both?) it's hard to say.
So physical vs. elemental damage, flat reduction vs. % reduction, there are lots of combinations. I'm not sure which the engine should handle, or the best way to make it generic.
Further, whether to treat these reductions as a fixed value or have diminishing returns. Maybe 100 resistance reduces incoming damage by 50%, but 200 resistance reduces damage by 75%. 300 resist for 87.5%. etc. Maybe the level difference betwen the attacker and defender adds in to the formula. Maybe the attacker can have a Piercing stat that ignores some amount of resistance.
At any rate, instead of making a very convoluted system to handle all cases, maybe it's best to isolate these calculations into a calculations class. Then at least someone changing the engine would have to do so in one place.
The transformation stuff is pretty new and WIP.
1. Set the enemy txt file to flying=1
2. Not sure yet, maybe igorko can help there
3. Set the enemy txt file to attunement_fire=0. That will multiply fire damage by 0. (default = 100, which is interpreted as 100%, so it multiplies damage by 1). So to take double damage from fire you'd say attunement_fire=200
"The authors of this content agree to license it under later versions of the licenses they selected above."
This means that the original artist has agreed to allow future versions of the specified licenses. For instance, Creative Commons licenses are version 3.0, but 4.0 will be the standard one day (and 5.0, etc). This is our way of saying the artist has already accepted future versions of this license.
You as the user of this art are still free to choose any one license.
You need the following development libraries:
SDL
SDL_image
SDL_mixer
SDL_ttf
There are new .pot files that contain the up-to-date strings.
If you have a .po editing tool, it should allow you to merge those new strings into the *de.po files. Unfortunately I'm not very familiar with those tools. Let me see if I can get someone else to chime in on this.
Feel free to email me the .po files, attach them here, or fork on GitHub. Any method is fine!
It's a thought.
The file name prefixes help there somewhat. All the Menus, Widgets, and GameStates are grouped together, and most of the remaining files are harder to categorize.
You retain copyright, as with all submissions to OpenGameArt.
(The obvious exception being if you specifically release your content to the Public Domain)
davis123,
Thanks! I'm not really sure if the way my game is done is typical, but it seems to be easy to follow. In the end, as long as it works (the players won't care) and it's easy to maintain/update, it's good enough.
Maybe I can do a timelapse or tutorial one day about making Flare assets. Besides the camera position and output scripting, actually creating the models is mundane -- any Blender tutorial will be helpful there. Sometimes I get textures from OGA, sometimes I use some Public Domain sources (like the Blender Texture CD).
I imagine Diablo has a base MapGenerator interface and several derived classes for each major map type. Random map generation can be done in many ways. You might create rooms first, then connect them with hallways. You might use a Maze generating algorithm. You might create rooms, then enlarge them until they overlap with another room. You might have a few prebuilt chunks that you combine in a few random combinations. Or some weird combination of algorithms. I'm sure one day Flare will support random maps, but I don't yet know what method we'll use. I'll need to study up on existing algorithms.
Pages