Talk:Complete Roguelike Tutorial, using python+libtcod

Currently, the semi-official discussion for this tutorial is available in the libtcod forum, at:

http://doryen.eptalys.net/forum/index.php?topic=328.0

Jotaf 16:47, 7 December 2009 (UTC)

My consern is the dotted borders around code. Why is the regular wiki style not enough? Especially the one-line snippets really attack the eyes. I now styling is kind of a matter of preference, but there are many reasons why standards (or de-facto standards) are used (I know, citation needed, and one can argue that the regular wiki style is bad, but it does suite millions of people after all, e.g. through Wikipedia...) Aave

Hey folks: can I suggest the following?

# Hello, world!
print "Hello, world!"
print (a + b) * 5

I think the code examples look substantially better without the heavily dotted borders and dark-grey background. If you want borders and a background, you could just use <div style="border: dotted 1px rgb(128,128,128); background-color: rgb(240,240,240);">...</div> or something like that:

# Hello, world!
print "Hello, world!"
print (a + b) * 5

My two cents, —Thomas Larsen 02:45, 6 June 2010 (UTC)

Yes, I had reservations about it too, but I couldn't find a different combination that I liked so I left it alone. Thanks for the tips, I changed the first section to Thomas's suggestion and it looks much better; I also went ahead and decided to make it a lighter solid border that doesn't look very different from a 1 pixel dotted line. Tell me what you think, if it's alright I'll change the rest too. A direct link. Jotaf 00:30, 10 June 2010 (UTC)

I think the new border and background colour are much better. My only suggestion would be to add padding: 5px; or something similar: the code is currently right up against the solid border, and it looks quite "cramped". Cheers, —Thomas Larsen 04:31, 13 June 2010 (UTC)

Done. You're right that the padding is a huge improvement. I updated all the code blocks to the new style. :) Jotaf 01:33, 24 June 2010 (UTC)

Copyright/Copyleft

What licence is used for the tutorial code?

I haven't decided yet. I realize that since it doesn't have an explicit license it's copyrighted by the author, me, but I'll eventually change it to a proper license. I want people to be able to make their games out of this without weird limitations, it's a tutorial after all -- I just need to decide on the details! Jotaf 23:39, 1 April 2011 (UTC)

so would you be ok with me using cc-by-sa and linking to this page? Elvis 12:04, 5 April 2011 (UTC)

I'm more inclined to use the BSD license, but I'm open to suggestions. Why would cc-by-sa be better? Since there's some interest I'll decide ASAP, in a few days at most, but until then feel free to make your case for one license over another. Jotaf 02:04, 6 April 2011 (UTC)

Creative Commons says it doesn't recommend its use for software... http://wiki.creativecommons.org/FAQ#Can_I_use_a_Creative_Commons_license_for_software.3F Jotaf 02:13, 6 April 2011 (UTC)

i have knowledge using the cc licenses, and i quiet like them, but i am also open to others. you can also say the code is usable under cc-by-sa OR bsd OR ... i have only little knowledge of the bsd licence, so i can not say which one is better or worse Elvis 02:16, 9 April 2011 (UTC)

I'm going with BSD; but really, it's not incompatible with CC. You can basically add your name (in addition to mine) and release it under the same license, or add your chosen license terms right under mine. Really, the only thing required is that you keep the short license text, and other than that you can go crazy with the code. I know the tutorial doesn't have the license right now, that will change, but if you want to release now, here it is:

Copyright (c) 2011, Jo??o Henriques
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
    * Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.
    * Redistributions in binary form must reproduce the above copyright
      notice, this list of conditions and the following disclaimer in the
      documentation and/or other materials provided with the distribution.
    * The names of its contributors may not be used to endorse or promote
      products derived from this software without specific prior written
      permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL JO??O HENRIQUES BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Jotaf 15:45, 10 April 2011 (UTC)

I've been thinking more about this, and I think I will just leave it in the Public Domain. Opinions?Jotaf (talk) 03:37, 17 December 2012 (CET)

I think keeping it in the public domain is a good idea; other users will be able to distribute their games without having to worry about rights and use issues. FredNotBob (talk) 00:01, 19 December 2012 (CET)

Page naming

I have two suggestions:

1. Can we move this to a shorter and, I dare say, more catchy title?
2. Can we use subpages? For example, "Complete Roguelike Tutorial, using python+libtcod/Part 3"?

Nnz 04:59, 6 August 2011 (CEST)

1. If you have any suggestions, please let me know :) Though since some people already know this tutorial by this name, I hope it's a good improvement; if it's just reshuffling or dropping some words it might not be worth it. It's a long name but you'll notice it has the right keywords - it's a tutorial for a complete game; and it says the language and library to set it apart from other tutorials which use other languages/libraries.

2. Good idea, but there isn't a huge difference between the current method and subpages. Still, if the name is changed then it's probably a good opportunity to go ahead and use subpages. Jotaf 14:13, 31 August 2011 (CEST)

Page update

I'm working through this tutorial, and it's very good, but some of the routines in libtcod have changed names between release 1.5.0 and 1.5.1. Would anyone object if I were to update the tutorial to use the newer API?

Ok so the main issue is that the event system's interface is messy, and it would be much more preferable to use the previous interface. It still exists (the keypress/mouse_status functions weren't removed) but they're broken in this new version. I'm pasting here a message by Muscles on this issue, in case anyone has any suggestions. Jotaf (talk) 03:52, 17 January 2013 (CET)

I had noticed the double keypress in the early tutorials, but didn't worry too much about it since it got fixed when I introduced the event system, and combat isn't an issue in the early parts. The big problem was that the mouse detection didn't work reliably with mouse_get_status(). I found reports on the forums of this and the advice given was to move to the event system.

I feel a little bit annoyed that a point release of libtcod made so many API changes. Usually you would expect a full version number increase (to 2.0.0) when such API changes occur. It also would have been trivial to have included functions to convert from the old API to the new one in the libctodpy.py file; I didn't want to do this myself as that's not a file I can change - I would have needed to ask the user to add such functions I supply to third party code.

I also think the introduction of such significant bugs as mouse_get_status() no longer working and console_wait_for_keypress() returning twice would be reason to put out 1.5.2 as a bug fix, and making the in-development version 1.5.3 or later. If you have any influence over the developers of libctod, pushing a 1.5.2 bugfix release would be my preferred option.

Otherwise, I would suggest using and explaining the events system right from the early parts of the tutorial. It does seem that this is the future direction of libtcod and we will need to support it at some point.

It is of course trivial to restore the tutorial to the 1.5.0 version using article history to revert recent changes. It would also be possible to later go back to the versions I edited, but if anyone makes any changes in the meantime, they would have to be manually re-added which might get messy.

I suggest you copy this discussion to the talk page of the wiki at Talk:Complete Roguelike Tutorial, using python+libtcod to see if others weigh in. I'm a great fan of collaborative work.

-Muscles, 17 December 2012

Also, as I work through it, I'm making small changes to my version of the code eg slightly cleaner dungeon-generation code, slightly smarter monsters, allow the player to use the numeric keyboard as well as the arrow keys. Would it be okay if I added my versions of these routines to the extras section, and mentioned them as appropriate in the main body of the tutorial?-Muscles (talk) 03:30, 23 October 2012 (CEST)

I've now updated the tutorial, making minimal changes to the actual logic. The one change I did make was to implement numeric keypad movement in lesson 11. I'll check the extras section for necessary changes for 1.5.1, and then I'll add other suggestions to the extras section, as above.

Does anyone have suggestions for further lessons in the series? I might modify the existing extras code for scrolling maps to make it lesson 13.-Muscles (talk) 05:10, 13 November 2012 (CET)

Just an update on this point, part 13 is out and 14 is already planned (it will wrap up the tutorial). Everything else, like scrolling maps, will be an extra!Jotaf (talk) 03:52, 17 January 2013 (CET)

Suggestions

Hi there, maybe a food/starve/fainting part would be nice ? Regards BJB (talk) 01:52, 24 December 2012 (CET)

Well I was hoping that kind of system could be coded by people themselves. You'll notice the combat system is very basic too. So the unique thing that will distinguish your RL will probably be those game mechanics. A food/starve system can be just a counter you decrease every turn, and using some items increase it. Fainting may be one effect, another could just be adding some penalty to attack/defense! Jotaf (talk) 05:48, 26 February 2013 (CET)