The layers are read into an array when loading the map. The array or each layer can be altered at runtime of course.
For example have a look at the caves map east of the map with guill and ukonen. Once you enter the map, you are warned not to go south or the wall breaks down. If you go there however, both the collision layer (which you cannot see, but must be consistent to the visible layers) and the objects layer showing the walls change, so you need to find another way out.
If you want to checkout a tutorial on maps, please have a look at the devlab branch of my repository. The devlab is a mod for flare to explain the flare engine and how it works to new contributors. It is however not yet completed and done. At my branch devlab however you find a decent amount of tutorial regarding maps and mapping in flare.
Adding features is most of the time checking if the new feature works out great visually, which is rather done by a human than a bot.
If you need to test specific parts of the game, you can easily modify your save game files and adjust your level, your skills and money and items.
The save file is usually found in ~/.local/share/flare/ if you're running a unix like operating system. If you're using windows there should be a saves folder inside the flare folder where you find the save files.
fellow german here: your english is great ;) (or I am overlooking the typical german english errors)
The best way of contribution is generally to first find a topic which is most interesting for you, so you'll really love doing it. We're most often discussing development either at the github site in the issues for a specific solution or via IRC these days. (IRC: real time chat possible, github issues not so much)
You seem to be interested in maps specifically. Then I'd recommend to not look into the source code of flare, but rather in tileds source code. Flare rendering is highly optimized, see https://github.com/clintbellanger/flare-engine/blob/master/src/MapRender... how to render one map layer for example. I tried to comment it, but most likely not enough.
So maybe as a general note: A map is tile based and structured in layers. A tile is a small picture, such as a certain are of the floor or a throne or a piece of the wall. A map consists of multiple 2D layers which are drawn above each other. In flare that is the background layer and the object layer. Additionally there is a collision layer, which you can see in tiled, but not in flare. The collision layer just defines on which tiles the hero can walk, where are walls, where there are obstacles, but i.e. arrows can still fly there.
The background layer is put into the background such as the floor where the hero and enemies are walking on. The object layer is on the same 'height' as the hero and enemies, so you need to care about the rendering order, i.e. the hero standing in front or behind a wall makes a difference in the rendering order.
Another thought which came up during discussion on irc: (Feel free to join #flarerpg at freenode :)
Maybe we could implement the minion system by just exchanging/adding the EnemyBehaviour class. So we would not need a MinionBehavior and MinionManager, which currently has copied lots of the respective EnemyManager and Behavior class. Instead the minion is technically an enemy, just with a different behavior.
This would bring some advantages:
Maybe less duplicate code (Manager class, behavior class, enemy/minion class itself)
Easy switching during runtime: Consider a Ranger taming animals. Or if you are dealing damage to your minion, it turns against you. This would be probably be easier to do, as only the enemybehavior class would need to be changed.
The layers are read into an array when loading the map. The array or each layer can be altered at runtime of course.
For example have a look at the caves map east of the map with guill and ukonen. Once you enter the map, you are warned not to go south or the wall breaks down. If you go there however, both the collision layer (which you cannot see, but must be consistent to the visible layers) and the objects layer showing the walls change, so you need to find another way out.
If you want to checkout a tutorial on maps, please have a look at the devlab branch of my repository.
The devlab is a mod for flare to explain the flare engine and how it works to new contributors. It is however not yet completed and done. At my branch devlab however you find a decent amount of tutorial regarding maps and mapping in flare.
https://github.com/stefanbeller/flare-game/tree/devlab
I intend to get my devlab version merged after the upcoming release this weekend.
Specially for mapping and tilesets there is this
http://www.flarerpg.org/tutorials/isometric_intro/
https://github.com/clintbellanger/flare-engine/wiki/Tile-Set-Definitions
Adding features is most of the time checking if the new feature works out great visually, which is rather done by a human than a bot.
If you need to test specific parts of the game, you can easily modify your save game files and adjust your level, your skills and money and items.
The save file is usually found in ~/.local/share/flare/ if you're running a unix like operating system.
If you're using windows there should be a saves folder inside the flare folder where you find the save files.
Hi Arivor,
fellow german here: your english is great ;)
(or I am overlooking the typical german english errors)
The best way of contribution is generally to first find a topic which is most interesting for you, so you'll really love doing it.
We're most often discussing development either at the github site in the issues for a specific solution or via IRC these days.
(IRC: real time chat possible, github issues not so much)
You seem to be interested in maps specifically. Then I'd recommend to not look into the source code of flare, but rather in tileds source code. Flare rendering is highly optimized, see https://github.com/clintbellanger/flare-engine/blob/master/src/MapRender... how to render one map layer for example. I tried to comment it, but most likely not enough.
The tiled source code is in my opinion better readable as it actually puts more emphasis on readability than performance.
The same code (rendering a map layer) is here https://github.com/bjorn/tiled/blob/master/src/libtiled/isometricrendere...
So maybe as a general note:
A map is tile based and structured in layers. A tile is a small picture, such as a certain are of the floor or a throne or a piece of the wall.
A map consists of multiple 2D layers which are drawn above each other. In flare that is the background layer and the object layer. Additionally there is a collision layer, which you can see in tiled, but not in flare. The collision layer just defines on which tiles the hero can walk, where are walls, where there are obstacles, but i.e. arrows can still fly there.
The background layer is put into the background such as the floor where the hero and enemies are walking on. The object layer is on the same 'height' as the hero and enemies, so you need to care about the rendering order, i.e. the hero standing in front or behind a wall makes a difference in the rendering order.
Could you be more specifc, which spells you are referring to?
Both where/what you saw in flare and what kind of spell you are referring to in Diablo. (Images would be great :)
Just as Ryan said: flare is very easy to mod and experiment with, so if you already saw it in action within the game, you can get it as well easily.
Please mind http://www.flarerpg.org/blog/20130321
Another advantage to the idea: We already have lots of enemy code there, like showing a HP bar.
http://webchat.freenode.net/?channels=flarerpg for those who are unfamiliar with irc
Another thought which came up during discussion on irc:
(Feel free to join #flarerpg at freenode :)
Maybe we could implement the minion system by just exchanging/adding the EnemyBehaviour class.
So we would not need a MinionBehavior and MinionManager, which currently has copied lots of the respective EnemyManager and Behavior class. Instead the minion is technically an enemy, just with a different behavior.
This would bring some advantages:
So if I understood Clint correctly, this is going to be in mainline after 0.18 is out (end of this month, http://www.flarerpg.org/blog/20130306)
Large changes/extensions are better pulled at the beginning of a development period, so lots of testing can be done.
Pages