2012
11.11

Developing free open source software has a lot of good sides. You grow a community, you get a lot of priceless feedback and a lot of motivation hard to find when you’re alone.

When confronted with an issue, some users dig on their own until they can provide a solution. Some lack the experience and just provide a detailed report. Both are very useful. But then there’s this third category of usersΒ  who just get angry. You can feel it in their first post even if they try to keep it civil. They hate you because your library does not work the way they intended. They think that you’d better not release something than release something not perfectly adapted to their use.

libtcod was released almost 5 years ago and during that time, I’ve been confronted with all sort of angry users. Some blaming the library for using x,y coordinates order. Some other blaming the makefiles for not providing an easy way to compile a static library, or not supporting the C++ string class and so on.

I’m not a consensual guy. For example, it’s no news that I don’t like proprietary technologies. Yet, I’ve done a lot to keep everybody happy, bloating the library with 3 different compilation systems, trying to maintain ports that I can’t even build myself. You know sometimes someone put a huge amount of effort to port the library to some new os/language, then, understandably (that’s not a paid job), stops maintaining it. The problem is that users then get angry because you don’t invest enough of your time on this port.

Generally, all this anger is just a background noise that is covered by the more positive feedback. But it can grow to a point where it becomes a real problem. You’re supposed to ignore it, not to take it personally, but I don’t seem to be able to do that.

Well I’m fed up with anger. It’s time libtcod realigns with my personal beliefs. This will leave a lot of people on the side of the road (and probably generate even more anger). I’m sorry for that, but I’m not here to make friends or to build a business. The source code is still available under BSD license. You can fork libtcod or use only the fov/pathfinding parts to build a better library. I just created a “edge_of_the_cliff” tag you can use to start your fork. You could also use the 1.5.1 tag but there have been quite a few fixes since this release.

Here are the things that will change starting with the 1.5.2 release :

  • drop support for Visual Studio
  • drop support for OSX
  • drop C# port
  • drop cmake/automake/swig support

On the bright side, I’ll make some documentation effort for users using the supported tools. The C++ tutorial is part of that effort, but the libtcod documentation definitely needs more work. Things you can expect in the short term :

  • documentation about how to compile the library
  • documentation about how to start a project from scratch
  • functions index

In the medium term, I intend to merge Umbra and libtcod-gui and provide a documented GUI toolkit with the library, something that has been lacking since the beginning.

The long-term vaporous goals are still lua and android ports, but don’t hold your breath.

21 comments so far

Add Your Comment
  1. Sounds perfectly reasonable to me.

  2. Cool. At least one person I didn’t alienate πŸ™‚

  3. You have my full support. Sure, sad to see OSX support go, but if it benefits the library, I’m all for it.

  4. aw no more c# libtcod πŸ™ But you are right on the money, do what you feel you need to do. It’s a sad state of affairs when people will moan and whine about something amazing they get to use for free.

  5. Thumbs up. I fully agree with you and your reasoning.
    As for integrating Umbra, I’m bloody thrilled about that one! Maybe it’ll help me move my butt and get back to writing C++ πŸ˜‰

  6. That would be awesome ! πŸ™‚

  7. Good decisions imo.

  8. More power to you jice! You can’t please everyone, and it can be hard to fend off the idiots on the Internet… Does a lot of the negativity come from e-mails? I occasionally check out the forums to see what people are working on, and most everyone there is pretty polite and certainly very grateful for your awesome support.

    Merging Umbra is also a great idea, since I believe it could be incredibly helpful for people starting out who might have trouble figuring out how to organize a more dynamic UI rather than just a map with text overlays, but it doesn’t have very high visibility compared to the core libtcod library.

  9. You’re doing what you need to do – if you give someone $5 they’ll complain it isn’t $10. People will take free content, free libraries, free games, free anything, and find a way to complain about it. The fact that you’re doing this project at all is commendable, and it’s helped a lot of developers.

  10. Although it was very nice of you to support and invest your time in all the different paths libtcod has taken, it’s totally reasonable to concentrate your efforts on one of them. After all this is libtTCOD, just a humble library for an epic game and you cannot suit everybody’s needs.

  11. Thanks for all the hard work you’ve put into this. I am sad to see MacOS X support go, as it was with a libtcod library and the 11-step “build a roguelike” tutorial that I got into programming in the first place. I tip my hat to you good sir and wish you great success in this next step.

  12. What do you mean by “Drop support for OS X”? I’ve been using LibTCOD for an OSX project, but I’ve just been building the library myself from source. I assume this shouldn’t be a problem, still? Also are you still open to accepting extensions/patches/etc?

    I totally understand the need to “pare down” the code to what you need/want it to do. I do however think it’s important not to throw the baby out with the bathwater and reject the value added that open-source input can provide.

  13. Yeah you’re free to build the library, I can put a link to your build in the third party ports. I’ll apply provided patches in the code, but I won’t store OSX specific files in libtcod’s hg repository.

  14. When you say “drop swig support” does that mean that you will no longer bundle libtcod with a pre-built python lib? I’ve been playing roguelikes for years but that what finally got me coding one! Thanks for all your effort and providing libtcod to the community!

  15. nope. the python lib is handcrafted. It’s not using swig.

  16. Bummer dude. I understand that it’s your project and you’re free to do whatever you want and it seems like you have legitimate reasons for doing this or whatever but man… it’s been a fun few years toying around with making roguelike projects with C# and libtcod, sucks to see that that’s going away.

  17. @takua108: the lack of C# support doesn’t mean libtcod won’t be useable with C#. It’s just you’ll have to rely on third party builds as they won’t be included in libtcod directly.

  18. For Mac users, I’ve already made progress on compiling 1.5.2 on OS X (10.6). I’m a total novice with regard to makefiles and linking and such, so my solution is probably inelegant and perhaps horrible, but it does *work*. See my post here:

    http://doryen.eptalys.net/forum/index.php?topic=1414.msg8625#msg8625

  19. Fair enough, but I do think you’re making a mistake to exclude files that allow compilation on OSX. OSX is a lot more popular than Linux, and I expect its popularity to continue to grow at Windows’ expense. Arguably the best-known roguelike using libtcod is Brogue, and that is developed on OSX. Maybe you could keep the osx makefile etc in the repo but state that you take no responsibility for it, and that others have to be responsible for keeping it up to date?

    If you don’t want to do this, then someone should make a fork of the libtcod repo, that adds in the stuff necessary for OSX compilation. This seems pretty straightforward on bitbucket:
    https://confluence.atlassian.com/display/BITBUCKET/Fork+a+Repo,+Compare+Code,+and+Create+a+Pull+Request

    Also, I would suggest that Umbra should stay as a separate library (libtcod-umbra.dll) rather than lumping it directly into libtcod. Just my 2c.

  20. A fork is defnitely the way to go. And yes., umbra will be a separate library.

  21. Good decision, IMO. You maintain the core library and others who want OSX/C#/etc. can fork and update their code when you push new changes. You can point to their forks in your docs. You can move faster without having to worry about the other versions, and others can move faster without having to coordinate with you. Decoupling is good!