Author Topic: 7DRL Challenge 2014 participants are invited to use Necklace of the Eye!  (Read 8537 times)

Z

  • Protector of the @
  • *****
  • Posts: 905
    • View Profile
    • Z's Roguelike Stuff
NotEye invites the 7DRL participants to create roguelikes using the NotEye library!

What is NotEye?
NotEye is a library which provides  graphics (traditional console look and feel, tiles, or modern third person view modes), as well as other features (accessibility functions for playing on laptops, recording, phpBB screenshots etc.). NotEye is used by the newest versions of  ADOM, PRIME, and Hydra Slayer. See ADOM or Hydra Slayer to see what NotEye can do (PRIME uses an older version of NotEye).

Are there any special rewards for accepting the invitation?
I am planning to support all the 7DRL participants using NotEye. This means, answering questions (about NotEye, general programming, or design), testing, whatever. If what you want is of general use, this might create quick new releases of NotEye. Use this RogueTemple thread, or e-mail (zeno@attnam.com). Also, your 7DRL will be included with the future versions of NotEye, which means that more people will play your game. This assumes the game is free software (open source), is not too bulky, has better quality than the samples currently included with NotEye (which are a @ moving on screen with more or less interesting one-hit-point monsters, depending on the language), and of course that you actually want it. (Bulky and non-free games might still be included in the NotEye bundle.)

Can I use NotEye for free?
NotEye is currently under GPL, which means that you can use it freely in your own GPL projects. This means that you have to release the source, and allow other people to modify your game -- thus, for example, you probably cannot use NotEye freely together with commercially licensed tilesets, such as the Oryx roguelike tilesets. If you do not like this, contact me, and we can make a deal (that is, a licensing exception, as it is done in ADOM).

But I do not know how to program...
You could try learning Python. See the Python course at Codecademy, or the official Python tutorial. Then, see the Python roguelike tutorial at RogueBasin  (it is for libtcod, but many things should work with NotEye, too).

What languages can I use?
NotEye 7.5 includes samples written in C, C++, Java, Python, and Free Pascal. To access more powerful features of NotEye, you also need to write a game script in Lua. (Otherwise the only graphics you get are ASCII characters in a boring ASCII dungeon. Not much, but I play DCSS myself in this mode, rather than pure ASCII or the official Tiles version.) See the NotEye development docs for more information about NotEye development. (I am still working on the docs.)

I am planning to write a pure ASCII roguelike. Why should I use NotEye instead of Curses (or another terminal library)?
If you want your game to run only on Linux, then Curses is fine. But there are many problems with Curses in Windows: it is impossible to go full screen, colors are weird, and so on. For this reason, most new roguelike projects use a more modern roguelike library (such as NotEye or Libtcod, aka the Doryen Library) rather than Curses. Also they provide a more portable keyboard handling than Curses. And note that NotEye has more features than just the funky graphical modes.

And why should I use NotEye instead of Libtcod?
NotEye is developed more actively than Libtcod. Also, NotEye has many more features than Libtcod (tile/3D graphical modes, streaming, laptop accessibility, etc.) Also, contrary to Libtcod, NotEye can output to a system terminal, which makes NotEye roguelikes playable online (using an SSH client) or by  blind players (at least in theory).

Okay, but why not simple write it in Libtcod or Curses? Apparently NotEye works with Libtcod and Curses games.
Yes, NotEye works with Libtcod and Curses games, but more advanced features (such as the smooth sprite movement or HP bars) work only for games using the NotEye library (which allows NotEye to access the game's functions, instead of just reading its screen). Also, this is quite slow and inconvenient -- especially with Libtcod, which is done by substituting the Libtcod library and breaks if the game uses a wrong version of libtcod (like Jeff Lait's great 7DRLs), and uses a TCP/IP connection between the two processes).

Are there any reasons to use Libtcod instead of NotEye?
Libtcod is a single file (plus the font file), while NotEye is much more bulky. Also, Libtcod provides several algorithms useful in programming of roguelike logic, such as field-of-vision or pathfinding. Although these tasks may seem daunting to newbies, in some cases using someone else's code is harder and less fun than writing your own, and there are simple solutions, too: pathfinding can be done with breadth-first search, and field-of-vision can be done simply by tracing a line from the player to each cell on the boundary of the map (not very efficient, but it should not matter in most cases). See the sources of Hydra Slayer where both of these approaches are used (functions  seeall() and bfs(...)).

How NotEye compares to T-Engine?
NotEye is just a frontend, while T-Engine is a full engine to write roguelike games -- basically, everything that is used in ToME can be used in a T-Engine game. On the other hand, T-Engine is very bulky, its games often look too much like ToME (which I don't like personally), and it seems hard to find documentation how to use it. And with T-Engine, you have to program the whole game in Lua, while NotEye  uses Lua only for the "game script" part, and gives more choices for the game itself.

How NotEye compares to Unity?
I do not know much about Unity, but from my experiences, it aims to be a tool to create 3D games, not roguelikes, and roguelikes written in it look quite strange in my opinion. It restricts your choice of programming languages, but extends your choice of systems where your game runs (although I had problems running it on Linux IIRC). Also Unity is commercial, while NotEye is GPL.

What if I want to create browser or mobile games?
Unfortunately, NotEye currently does not work on mobile OSes. I am planning to add support for mobile games in the future, but this is not done yet. No idea about browser games, too.

chooseusername

  • High Priest
  • ****
  • Posts: 329
    • View Profile
    • Email
Re: 7DRL Challenge 2014 participants are invited to use Necklace of the Eye!
« Reply #1 on: February 22, 2014, 07:19:31 PM »
Is NotEye purely graphical, or does it a form of text representation like curses? The reason I ask is that I wonder how playable text-based roguelikes are for the blind, and find it kind of a pity that choosing something graphical like libtcod or NotEye(?) cuts them off.

I think the use of GPL for a framework like this is a mistake, but it's your prerogative of course.  I'd be surprised if libtcod had become as popular if everyone was required to release the source of their game.

Z

  • Protector of the @
  • *****
  • Posts: 905
    • View Profile
    • Z's Roguelike Stuff
Re: 7DRL Challenge 2014 participants are invited to use Necklace of the Eye!
« Reply #2 on: February 22, 2014, 10:06:44 PM »
Yes, NotEye does have Curses-like output (in config, set "havegfx" to false and "havetext" to true, also change the display mode to pure ASCII). It works, although it is not a much requested feature, so it is not ideal (arrow keys do not work as well as they should). I would be happy to include some special features for blind players, but I would need them to tell me what they actually want.

I agree that GPL has its downsides, maybe I will reconsider the licensing later (other choices also have their downsides). But it seems that many of the popular Libtcod games are open source anyway (Brogue, most 7DRLs, ...), and bigger commercial projects can use NotEye by the means of a licensing exception, like ADOM does.

Quendus

  • High Priest
  • ****
  • Posts: 447
  • $@ \in \{1,W\} \times \{1,H\}$
    • View Profile
    • Klein Roguelikes
Re: 7DRL Challenge 2014 participants are invited to use Necklace of the Eye!
« Reply #3 on: February 23, 2014, 04:52:10 AM »
I would use NotEye for my 7DRL this year if it weren't GPLed. I don't object to making my game open source (in fact I make a habit of it), but I don't like to restrict the freedoms of anyone who might want to modify or repackage my work. For this I prefer to use permissive licenses like MIT or the Unlicense, and I can't use GPL code in such projects.

Eben

  • High Priest
  • ****
  • Posts: 339
  • Controversializer
    • View Profile
    • SquidPony!
Re: 7DRL Challenge 2014 participants are invited to use Necklace of the Eye!
« Reply #4 on: February 23, 2014, 11:33:38 AM »

What languages can I use?
NotEye 7.5 includes samples written in C, C++, Java, Python, and Free Pascal. To access more powerful features of NotEye, you also need to write a game script in Lua. (Otherwise the only graphics you get are ASCII characters in a boring ASCII dungeon. Not much, but I play DCSS myself in this mode, rather than pure ASCII or the official Tiles version.) See the NotEye development docs for more information about NotEye development. (I am still working on the docs.)


Do I understand correctly that this means if you don't use Lua, you only basically have an ASCII console window? If you do use Lua to get the more powerful features, what reason would there be to also use C / C++ / Java / Python / Free Pascal? Just for utility function support?

If it wasn't GPL, I'd add an interface from SquidLib for it but since my code is all Apache 2.0 I can't. Since Blacken development stopped more than a year ago, SquidLib is basically the only full-featured Java roguelike library and I'd love to be able to support as many other development tools and display engines as possible with it...

Z

  • Protector of the @
  • *****
  • Posts: 905
    • View Profile
    • Z's Roguelike Stuff
Re: 7DRL Challenge 2014 participants are invited to use Necklace of the Eye!
« Reply #5 on: February 23, 2014, 01:00:18 PM »
Without changing the Lua script you get something like this: http://roguetemple.com/z/noteye-img/java-sample.jpg (BTW if you are interested in the rules of the game: a herd of monsters is running somewhat randomly to the east, and the PC is on its way -- so you need to move in a way which prevents you from being trampled by the monsters). PRIME 2.1b manages to use full graphics (without smooth movement and streaming) with only 2730 bytes of PRIME-specific Lua script (just a simple glue code), everything else is made in C++. The idea is that you make a game in your preferred language, and only (some part of) interface is in Lua. In particular, if you have something which works with Curses or Libtcod etc., it should be possible to use with NotEye without having to translate to another language.

(By the way, just noticed that I have introduced a bug while making TPP work with hex -- it works only in hex, unless fppvar.xz is changed to (fppvar.xz or 1) in line 646 of viewmodes.noe. I will release a fix shortly)

As for licensing, my intention is as follows:

A game using a more permissive open source license (such as the MIT license or Apache 2.0 license) can use NotEye, but any derivatives which do something which is allowed by the permissive license but not by GPL would have to either avoid using NotEye or ask me for a licensing exception. Thus, if somebody wants to use your dungeon generator, they can do it, and if they want to create a commercial game based on your game, they would have to ask me for permission (or to use some other library).

Not sure about SquidLib... common sense says that is that if somebody wants to use SquidLib with the NotEye interface, they would have to do it under GPL, and if they want to use other interfaces, they can use the Apache License (so a dual licensing, GPL with NotEye, Apache without NotEye?)

Quendus

  • High Priest
  • ****
  • Posts: 447
  • $@ \in \{1,W\} \times \{1,H\}$
    • View Profile
    • Klein Roguelikes
Re: 7DRL Challenge 2014 participants are invited to use Necklace of the Eye!
« Reply #6 on: February 23, 2014, 04:02:23 PM »
As for licensing, my intention is as follows:

A game using a more permissive open source license (such as the MIT license or Apache 2.0 license) can use NotEye, but any derivatives which do something which is allowed by the permissive license but not by GPL would have to either avoid using NotEye or ask me for a licensing exception. Thus, if somebody wants to use your dungeon generator, they can do it, and if they want to create a commercial game based on your game, they would have to ask me for permission (or to use some other library).
How exactly would that work? Do you mean that a game written using NotEye must be GPL licensed, but the author of the game may choose a secondary license (MIT or Apache, no others?) and is granted an exception to the GPL which allows code derived from the game code to be distributed under the chosen secondary license if it contains no calls to NotEye code?

Edit: it looks like I can do that already by releasing my independently functional code under a GPL-compatible license such as MIT, and using it as a module in a GPLed project that includes NotEye. I guess that would mean my main() and display code would not be available under the permissive license.

Z

  • Protector of the @
  • *****
  • Posts: 905
    • View Profile
    • Z's Roguelike Stuff
Re: 7DRL Challenge 2014 participants are invited to use Necklace of the Eye!
« Reply #7 on: February 23, 2014, 05:21:17 PM »
As far as I understand, permissive licenses such as Apache 2.0 and the MIT License are compatible with GPLv3*, which means that a GPLv3 software can include parts licensed under a permissive license.

Thus, the game is released under GPLv3 as a whole, but it includes a part (the source code of the game, or at least its NotEye-independent part) which is released under MIT License. I am not a lawyer, and I cannot find any clear explanation of this particular case, but I think no licensing exception is required here. Dual licensing (as you say) should be an option too.

* Probably other permissive licenses too, I have checked just these two. Apache 2.0 is compatible with GPLv3, but not with GPLv2. Possibly I need to clarify that it is okay to distribute NotEye under GPLv3... it includes GPLv2, the game and the website display "version 2", only a comment in the source code says "either version 2 of the License, or (at your option) any later version".

chooseusername

  • High Priest
  • ****
  • Posts: 329
    • View Profile
    • Email
Re: 7DRL Challenge 2014 participants are invited to use Necklace of the Eye!
« Reply #8 on: February 23, 2014, 09:16:56 PM »
As far as I understand, permissive licenses such as Apache 2.0 and the MIT License are compatible with GPLv3*, which means that a GPLv3 software can include parts licensed under a permissive license.

Thus, the game is released under GPLv3 as a whole, but it includes a part (the source code of the game, or at least its NotEye-independent part) which is released under MIT License. I am not a lawyer, and I cannot find any clear explanation of this particular case, but I think no licensing exception is required here. Dual licensing (as you say) should be an option too.

* Probably other permissive licenses too, I have checked just these two. Apache 2.0 is compatible with GPLv3, but not with GPLv2. Possibly I need to clarify that it is okay to distribute NotEye under GPLv3... it includes GPLv2, the game and the website display "version 2", only a comment in the source code says "either version 2 of the License, or (at your option) any later version".
It is meaningless to license your own game as something simple like MIT or BSD, if you cobble it to something licensed by GPL.  Everything then becomes GPL-tainted anyway.  Honestly, regardless of my preferences, this is a mess and I doubt many who take it up will fully understand what they've taken on.

AgingMinotaur

  • Protector of the @
  • *****
  • Posts: 734
  • Original Discriminating Buffalo Man
    • View Profile
    • Land of Strangers
Re: 7DRL Challenge 2014 participants are invited to use Necklace of the Eye!
« Reply #9 on: February 23, 2014, 10:04:59 PM »
Licensing questions can get quite messy. Regardless, GPL is a pretty popular license (I like it, though I(am)ANAL and all that), and I must say this is a nice initiative from Zeno. Here's hoping it will generate some response.

As always,
Minotauros
This matir, as laborintus, Dedalus hous, hath many halkes and hurnes ... wyndynges and wrynkelynges.

Quendus

  • High Priest
  • ****
  • Posts: 447
  • $@ \in \{1,W\} \times \{1,H\}$
    • View Profile
    • Klein Roguelikes
Re: 7DRL Challenge 2014 participants are invited to use Necklace of the Eye!
« Reply #10 on: February 24, 2014, 04:37:59 AM »
As far as I understand, permissive licenses such as Apache 2.0 and the MIT License are compatible with GPLv3*, which means that a GPLv3 software can include parts licensed under a permissive license.

Thus, the game is released under GPLv3 as a whole, but it includes a part (the source code of the game, or at least its NotEye-independent part) which is released under MIT License. I am not a lawyer, and I cannot find any clear explanation of this particular case, but I think no licensing exception is required here. Dual licensing (as you say) should be an option too.

* Probably other permissive licenses too, I have checked just these two. Apache 2.0 is compatible with GPLv3, but not with GPLv2. Possibly I need to clarify that it is okay to distribute NotEye under GPLv3... it includes GPLv2, the game and the website display "version 2", only a comment in the source code says "either version 2 of the License, or (at your option) any later version".
It is meaningless to license your own game as something simple like MIT or BSD, if you cobble it to something licensed by GPL.  Everything then becomes GPL-tainted anyway.  Honestly, regardless of my preferences, this is a mess and I doubt many who take it up will fully understand what they've taken on.
It wouldn't be meaningless if logic and display are properly modularised and an alternative display method allows a complete permissive-licensed game to compile and run.

Nevertheless, when my intention is to minimise the legal nonsense and obligations faced by someone who wants to use my game code for any purpose, using GPL code seems very counterproductive.

It doesn't help that the FSF fails to provide clear documentation of this option in their FAQ. Instead we have two questions about the definition of compatibility, links to an opinionated tract about the evils of permissive licenses, and no information about which parts of a GPL project using a foreign GPL library can be released under a compatible license, or what hoops have to be jumped through to do so.

mushroom patch

  • Protector of the @
  • *****
  • Posts: 533
    • View Profile
Re: 7DRL Challenge 2014 participants are invited to use Necklace of the Eye!
« Reply #11 on: February 24, 2014, 04:21:10 PM »
Using libraries etc. licensed to you under the GPL requires that you release your own derivative work under the GPL as well (if you release it at all, which you obviously don't have to). It is worth noting, though, that the copyright holder of the code you were licensed under the GPL is free to offer you alternative licensing options (e.g. a commercial or just totally free BSD-style license) upon request, as long has his work isn't itself a derivative of other GPL licensed code.

The point is, authors may release their work under different licenses to different parties. It's apparently a viable business model, even.

Quendus

  • High Priest
  • ****
  • Posts: 447
  • $@ \in \{1,W\} \times \{1,H\}$
    • View Profile
    • Klein Roguelikes
Re: 7DRL Challenge 2014 participants are invited to use Necklace of the Eye!
« Reply #12 on: February 24, 2014, 04:50:32 PM »
Thanks, now I know how copyleft works.

I think I'll just release my game into the public domain using curses as a library. A separate derivative game can borrow the PD code, link NotEye, and be released under the GPL (with prominent links to the original clean version). A horrible, ugly solution, but it'll do for this year.

mushroom patch

  • Protector of the @
  • *****
  • Posts: 533
    • View Profile
Re: 7DRL Challenge 2014 participants are invited to use Necklace of the Eye!
« Reply #13 on: February 24, 2014, 05:34:59 PM »
To clarify, you're not saying NotEye libraries provide convenience functionality for writing games targeting a traditional console or terminal emulator, you're saying that it can take raw control character output from such a program and convert into some kind of 3d or similar graphical interface, right?

re: ssh, are you saying that you can interface a ssh session with NotEye to play with a graphical interface on remote servers? (If so, that sounds kind of good -- though I guess if NotEye does what's in the first paragraph, it should be able to do this too in more or less the same way...)


Quendus

  • High Priest
  • ****
  • Posts: 447
  • $@ \in \{1,W\} \times \{1,H\}$
    • View Profile
    • Klein Roguelikes
Re: 7DRL Challenge 2014 participants are invited to use Necklace of the Eye!
« Reply #14 on: February 24, 2014, 05:59:54 PM »
That seems to be one of the ways NotEye works. See http://roguetemple.com/z/noteye-dev.php. It also has the option to replace the libtcod dynamic library at runtime, and (I presume?) a curses dynamic library. Or a C/C++/etc. program can be written calling NotEye functions.

It's not clear to me which features of NotEye are available in these different use cases. For example, smooth movement requires NotEye to know some information about actors' positions on the previous turn - does that information need to be provided by calls to NotEye functions or by some interface between the game and the Lua display script?