Nice! The water seems a bit too disperse though. What I did when coding the random world map generation for Wyrmsun was to implement "seeds" of mountains, which then would randomly expand or not, and from mountains, hills would be able to expand, and from hills plains. Here is a result of this random map generation algorithm (look at the minimap to see the entire world):
"Yes it is from austria. This flag was for a CTF map that takes place near the present german/austrian border, in an alternative timeline where another Holy Roman Empire or equivelant is ascendant (but still medeval in tech). The map in question is "OpposingCastles", it can be found in the ChaosEsque fork/mod/distribution of Xonotic, amongst many other maps by various contributors."
"I wrote germanic rather than german as this is for a fantasy part of a game. It is a replacement for the red team flag, thus the german colours were appropriate. The austrian arms makes the flag look more medeval and hints at a central european state such as the holy roman empire or the hapsburg empire."
I don't think it applies to them. The rest of that answer reads:
"What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."
Graphics would generally be used in forms similar to command-line arguments, and as such seemingly would be "mere aggregation". This answer in that FAQ is also relevant for this issue:
It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.
If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.
"If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program." If this is the case for plug-ins, then graphics and other sorts of content would be fine too. Furthermore, as I said previously, a lot of projects use different licenses for code and artwork - meaning that there is a general understanding that they are in mere aggregation. There are also commercial games that have code under the GPLv2, while keeping the artwork proprietary (an example: Frogatto) - if they can do this, then you can also the reverse, and have proprietary code and open-source artwork.
Any chance of dual licensing under the GPLv2 as well?
Absolutely awesome!
Nice! The water seems a bit too disperse though. What I did when coding the random world map generation for Wyrmsun was to implement "seeds" of mountains, which then would randomly expand or not, and from mountains, hills would be able to expand, and from hills plains. Here is a result of this random map generation algorithm (look at the minimap to see the entire world):
https://dl.dropboxusercontent.com/u/1732902/Wyrmsun/screen_random_world_...
Perhaps you could do something similar, but using plains seeds directly.
I think the item pack and etc. are fine, but I agree that the female Link spritesheet could represent an issue.
"Yes it is from austria. This flag was for a CTF map that takes place near the present german/austrian border, in an alternative timeline where another Holy Roman Empire or equivelant is ascendant (but still medeval in tech). The map in question is "OpposingCastles", it can be found in the ChaosEsque fork/mod/distribution of Xonotic, amongst many other maps by various contributors."
"I wrote germanic rather than german as this is for a fantasy part of a game. It is a replacement for the red team flag, thus the german colours were appropriate. The austrian arms makes the flag look more medeval and hints at a central european state such as the holy roman empire or the hapsburg empire."
Oh, that's an interesting backstory :)
I'm glad you like them!
I'm glad you liked it :)
Thanks! :)
The eagle is indeed from Austria; that is the Austrian coat of arms. And yes, the eagle in the Austrian coat of arms DOES hold a hammer and a sickle.
I don't think it applies to them. The rest of that answer reads:
"What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."
Graphics would generally be used in forms similar to command-line arguments, and as such seemingly would be "mere aggregation". This answer in that FAQ is also relevant for this issue:
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.
If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.
"If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program." If this is the case for plug-ins, then graphics and other sorts of content would be fine too. Furthermore, as I said previously, a lot of projects use different licenses for code and artwork - meaning that there is a general understanding that they are in mere aggregation. There are also commercial games that have code under the GPLv2, while keeping the artwork proprietary (an example: Frogatto) - if they can do this, then you can also the reverse, and have proprietary code and open-source artwork.
Pages