March 2015 - tsc-devel - Lists.Secretchronicles.Org

Licensing for your Secret Chronicles Theme Songs - We will have to remove them if we cannot reach you...

by Chris Jacobsen

Johan, Quintus emailed you on March 7th about licensing for the title and credits themes that you wrote for "The Secret Chronicles of Dr. M.". He emailed you at a m4um.net account, so I'm not sure if you would have gotten it. He outlined several possible license options - CC-BY 4.0, CC-BY-NC 4.0, a custom license, and sublicensing (I pasted his email below -- see that email for details on these options). Currently the music falls under an exclusive license by default, which technically means it can't be used for forks of our game or be used in our own game when it is placed in application repositories. Thus if we don't succeed in changing the license, we will be forced to remove these two songs from the game for the current release and would eventually have to seek out different theme songs in later releases. We really do not want to do this because your music is very good, but we cannot release version 2.0 of the game until we have answered these questions. We're running out of time for the release, unfortunately. Let us know what you think might work for this. We will be glad to answer any questions you have. We really appreciate your giving these songs to the project and hope to work with you again. -Chris (datahead) --------------------------------------------- Hi jobromedia, we have been discussing the licensing of assets in TSC (again), and after we’ve sorted out a major problem with Bugsbane’s graphics[1] we’d like to properly confirm licensing of the title (and credit) theme song as well so that we can release the 2.0.0 final version without any licensing problems remaining (hopefully). On the forum, you have granted us permission to use these songs[2] “for Secret Chronicles”, but that leaves open what happens further down the road, especially in the following cases: * People forking TSC and reusing the music * People coding an entirely new game and copying the music from our repository * Linux distributors packaging the game and distributing it on their own There has been some discussion on how we want the title song to behave in these cases, but not come to a final conclusion on it. Also you as the author of the song should really be asked as well. So far, the following has been suggested: * A CC-BY 4.0 license. This is the most easy option which will not cause any further problems and is what we endorse for any new assets. * A CC-BY-NC 4.0 license, forbidding commercial use of the song, but otherwise being equal to the other assets with regard to licensing. * A custom, complicated, detailed license that allows Linux distributors to convey copies of the song when they don’t change the code, but does not allow forks of the game to use the song. The last option is the one that requires most work, especially as it probably requires to be able to grant use permission on a per-case base. This is effectively a right to sublicense the song, and I don’t think you want to grant us that (although we’d appreciate it of course). This leaves us with the two CC options, unless you have some other suggestion, which we’re of course open to. I’d personally prefer a CC-BY 4.0 license, though datahead has expressed a preference to CC-BY-NC 4.0. Ultimately, it is up to you as the author to decide. Feel free to ask any questions. Vale, Quintus [1]: https://github.com/Secretchronicles/TSC/issues/356 [2]: http://forum.secretchronicles.de/topics/122/posts/617

4 years, 10 months

1
0
0 / 0

Possible uses for packages.

by Brian Allen Vanderburg II

The packages mechanism provides a way to isolate one set of game data from another, and allows one set of game data to depend on resource data (images, sound, music) from other packages. I originally had in mind that this could be used by other level developers to develop levels that are outside of the scope of the game use packages so that the data doesn't pollute the main game data. I'm thinking that it may also be usable for the main game to use packages, possible both for game play data (levels, worlds, and campaigns) as well as resource data. By using packages for game play data, it is possible to break the game up into separate scenarios, each with their own worlds, levels, and campaigns. This could be similar to how some DOS-based games had different scenarios that you could play independently of one another. The idea of using packages even for the resource data is for upgrades and compatibility. It may occur that some graphics could be modified during the development of the game. A change could cause level-breaking or other issues if the graphics change sizes, collision rectangles, etc. If the resource data is also in packages, then upgrading the graphics if it causes such problems can be done as follows: * Create a new resource package "tsc-core-v2" that depends on the previous/original resource package "tsc-core-v1". * Place any modified graphics in this new package, leaving the data in the original package alone. Here, a game play data "tsc-scenario1-v1" would depend on the resource package "tsc-core-v1". By placing the changed level-breaking graphics in the package "tsc-core-v2", the game play data from "tsc-scenario1-v1" would not be affected as it would still use the original v1 graphics. Also, any custom-developed packages would not be affected by changes done like this. An upgraded package can then be created that depends on "tsc-core-v2", lets call it "tsc-scenario1-v2". Since "tsc-core-v2" depends on "tsc-core-v1", any graphics not changed will still be used from "tsc-core-v1". A later scenario "tsc-scenario2-v1" may be created that depends directly on "tsc-core-v2". As the older packages are updated, the unmodified data from "tsc-core-v1" can be copied into "tsc-core-v2", the dependency on "tsc-core-v1" removed, and eventually "tsc-core-v1" removed from the game data entirely. (it may be archived somewhere for use by others if they still have old custom-developed packages that depend on it) I have attached an example graph to explain a bit more.

4 years, 10 months

1
0
0 / 0

[ANN] 1st General Discussion of the TSC team

by Quintus

Hi everyone, Luiji and me are proud to officially announce the General Discussion on 2015-03-21. Find the full text online (UTF-8-encoded text file if you experience display problems): http://team.secretchronicles.de/~quintus/general-discussions/1st-general-... It explains the entire precedure and contains the discussion schedule. Please, tell me or Luiji if you want to speak on one of the topics without being interrupted (see the announcement full text for details), which we recognise is very important to outlining your view of things. You should take this opportunity, because in open discussion there will be frequent interruptions with everybody being there and explaining and answering simultenously won’t work most of the time. You can just post your intention on the ML or in the forums or email us directly; in any case we’ll add you to the list of speakers in the full announcement. As explained, the full announcement text will be updated as more topics are suggested or people indicate they want to have some time for explanation. You might want to refresh the page thus from time to time if your browser only serves you cached versions. I will also post this on the forums. Valete, Quintus -- Blog: http://www.quintilianus.eu I will reject HTML emails. | Ich akzeptiere keine HTML-Nachrichten. | Use GnuPG for mail encryption: | GnuPG für Mail-Verschlüsselung: https://www.gnupg.org | https://de.wikipedia.org/wiki/GnuPG My key fingerprint: | Mein Schlüsselabdruck: B1FE 958E D5E8 468E AA20 | B1FE 958E D5E8 468E AA20 8F4B F1D8 799F BCC8 BC4F | 8F4B F1D8 799F BCC8 BC4F

4 years, 10 months

1
0
0 / 0

General Team Discussion in IRC

by Quintus

(I’m also going to post this on the forums) Hi everyone, it has turned out that there are some issues regarding TSC lying around that should be resolved once and for all by having a larger general discussion in IRC on them. The main issue is probably what has been suggested by datahead in IRC recently, namely the handling of the 2.x development branch after the 2.0.0 release. Apart from that there are some further issues we ought to discuss, and I think best way to do that is to have everyone from the team join an organised (i.e. ordered by topics) IRC discussion session. This requires first and foremost to find a date and time that allows every team member to join. I suggest the following for now: 2015-03-21 20:00:00 UTC Please object immediately if you know you are unavailable at this date or time. Discussion schedule until now: 1. Determing the voting process (proponent: Quintus) 2. Maintenance of the 2.x branch and opening of the 3.x branch (proponent: datahead) 3. Release date of the 2.0.0 release (proponent: Quintus) 4. Translation tools and services (proponent: Quintus) PLEASE SUBMIT MORE TOPICS FOR DISCUSSION! We don’t have the entire team in real-time chat that often. Take this opportunity and submit some topic that needs discussion and a binding result. As usual, for each topic we shall try to find a consent. If this isn’t possible, we shall vote on the topic. As we’ve not yet defined a proper voting process, I’ve put that topic first on the schedule, and am going to propose a voting procedure. By popular demand I’ll make a hopefully more easy suggestion than what I send to the mailinglist recently (needs are different in IRC anyway). I’ll post a more complete announcement with more detailed information on each of the topics and IRC modalities once we have the topics list complete by say, 2015-03-16. Please object if you don’t like this deadline. If you submit a topic, thus please give a short paragraph of overview that I can include into that announcement then so that even those people who don’t have followed this discussion can get a short overview of what’s going to be going on. PLEASE SUBMIT MORE TOPICS FOR DISCUSSION! Valete, Quintus -- Blog: http://www.quintilianus.eu I will reject HTML emails. | Ich akzeptiere keine HTML-Nachrichten. | Use GnuPG for mail encryption: | GnuPG für Mail-Verschlüsselung: https://www.gnupg.org | https://de.wikipedia.org/wiki/GnuPG My key fingerprint: | Mein Schlüsselabdruck: B1FE 958E D5E8 468E AA20 | B1FE 958E D5E8 468E AA20 8F4B F1D8 799F BCC8 BC4F | 8F4B F1D8 799F BCC8 BC4F

4 years, 10 months

4
6
0 / 0

2020

2019

2018

2017

2016

2015

2014

tsc-devel March 2015