Messages

16

Programming / Re: Viability of Python

« on: September 11, 2012, 01:04:43 AM »

I'm a huge Python fan.

Linux folks shouldn't have any issues with version differences. It's trivial for Linux users (using any reasonable Linux distro) to have multiple Python versions installed.

Before you pick the version of Python to use, make sure the extensions you want to use work with it. It can be non-trivial to recompile extensions for Python -- especially for Windows.

I'm specifically a Python 3 fan. The fixes put in place for Python 3 are useful and important for the growth of the language. More importantly, Python 3 is the future, and when folks use Python 2 impacts how quickly they can stop supporting two major versions.

If you use Python 2.x, expect everyone else to migrate to 3.x before you, and then the Python folks to drop support of 2.x, and then a major security issue happens and you're the last person effected by it. For a 7DRL you might not care about this. If you're trying to make a new major Roguelike, however, this could definitely be an issue.

Unfortunately, on Windows having Python 3 installed interferes with basically any other program that has features to use Python. (LibreOffice/OpenOffice fails to start if I have it include Python support, etc.)

Last time I looked at Python Roguelike development my requirement to use Python 3 meant I was writing my own UI code using TkInter. This was ~3 years ago, though.

My advice: Look in to py2exe (for Windows) and py2app (for Mac OS X). They'll allow you to make a first-class application using Python. Both py2exe and py2app work basically the same way, they create a ZIP file of the compiled Python code bundled with the Python interpreter.

To finish it off, on Windows you need to use a installer-creation program like the Nullsoft Installer. And on Mac OS X you'd create a "DMG" file. If you have access to Windows and Mac OS systems it is straight-forward to create packages for Windows, Mac OS X and DEB-based Linux distributions. (I've never created packages for other Linux package management systems so I can't say how easy it is.) At a university it should be possible to get access to both Mac OS X and Windows machines. Otherwise it's probably easiest to have a Mac and either dual-boot or have Windows in a VM. (Linux runs smoothly in a VM everywhere without license issues.)

By shipping your game as a standard installer for Windows and Mac OS X and source for everything else, you're basically completely covered in terms of making it easy for the folks that "need" it easy, and making it possible for the people using odd operating systems you've never heard of.

Cheers,
Steven Black

17

Programming / Re: libjcsi window size

« on: September 06, 2012, 05:06:49 AM »

Can someone familiar with the libjcsi library answer a simple question? What are the bounds on which I can draw without throwing errors? The window seems to be 25 X 80, but only throws errors when the 80 is exceeded. It seems to let me draw off the screen in the other direction as far as I want.

Anyone know what the true screen size is and whether its changeable?

libjcsi has some idiosyncrasies. Might I recommend one of the alternative libraries?

I know of at least two alternatives to libjcsi.

Eben Howard (one of the authors of libjcsi) has a more Java-like alternative in SquidLib:

    http://squidpony.com/not-games/squidlib/

I've written a small library to help with development of Java Roguelike games. Though we'll officially be releasing later this month, everything is ready now. I'm just trying to have it in Maven Central on the release date.

    https://sites.google.com/site/blackenlib/try-it-out (Java WebStart examples.)

Cheers,
Steven Black

18

Programming / Re: Resizing Terminal Screen

« on: August 30, 2012, 01:42:08 PM »

At least based on its documentation (I haven't actually used it), Urwid is the only console UI library I've ever seen that's actually based on modern UI library concepts. [...]

For Java, if using curses, there is: http://sourceforge.net/projects/javacurses/ -- It's an AWT subset implemented in Curses.

At some point in the future I want to see if I can make it use my Blacken AWT-based interface library instead. It'll probably mean a fork of javacurses, as I doubt it was designed for multiple back-ends.

It'll mean we'll have an AWT-like interface to a TUI running on AWT. It's so perverse I just have to try it.

Cheers,
Steven Black

19

Programming / Re: clean code

« on: August 29, 2012, 04:33:23 PM »

I want to point out that the data-driven approach (human-editable files with property definitions) and the object-driven approach (implementations and interfaces) need not be entirely different worlds.

The data-driven approach is great for massive numbers of nearly identical things.

For uniques, though? The Angband stuff has an explicit set of "unique" properties they set on the unique stuff. You end up dividing your logic between undescriptive data and custom logic elsewhere.

It makes more sense to have a combined approach. A system where the common stuff is super easy to make, but the unique stuff is super easy to maintain.

It shouldn't be particularly hard. You start with an Object system and the first object you make is the generic/common thing used by the data-driven objects.

The problem is that if you want deep interactions between objects (like, say, Nethack) you can easily end up tightly binding objects to each other. When objects are bound to each other, you end up dealing with an object system in which is complex to extend and requires non-obvious edits to fully add new subtypes -- no matter how you originally planned to design your object system.

This leads to many Roguelikes having elegant objects systems which actually prevent deep levels of object-object interaction. The simplest example of object-object interaction I can present would have to be dipping things in to potions in Nethack. You're dealing with an action with two different objects and an effect which is frequently similar -- but different than -- the standard player/monster potion effect. Depending on what is dipped (both the type of item and the existing intrinsic attributes it possesses) different results occur.

It's hard to write such interactions cleanly. It's even harder to have such a system be both clean and generic.

But... To me, the depth of interactions was part of the initial draw to Roguelikes. I don't care about the cleanliness of the code, I just care that the game is awesome.

20

Programming / Re: Resizing Terminal Screen

« on: August 28, 2012, 01:14:25 PM »

When you get to this stage, this is the highwater mark to equal or best outright:

http://users.freebasic-portal.de/rdc/tutorials.html

Thank you for pointing this out to me.

My plan is to write a small Roguelike, then write the tutorial backwards breaking it down in to simpler and simpler parts. While I was at it, I'd be fixing issues and adding features to my core library. The tutorial text becomes simpler because the code is already written. Plus if I can't explain something clearly in the tutorial it showcases a weak spot in the code.

I'm of the opinion that it's not a complete tutorial unless at the end there's an actual complete and playable game. I think it comes from learning to program as a kid and first wanting to play something and then wanting to understand and extend it.

My plan was to release it in ebook form, so it seems what I had independently been planning would have at least been a contender.

It's nice to have a benchmark on which to track my progress.

Again, thank you.

Cheers,
Steven Black

21

Programming / Re: Good Settings for Free-Roam RogueLikes

« on: August 28, 2012, 01:11:39 AM »

One day I want to play a roguelike made by a historian of the medieval era.

A guy I work with has a doctorate in mideval literature. He's a developer because the initial doctors in that field would be paid a fraction of what he's being paid now.

He periodically writes articles about midevalism and video games.

I talk a lot about Roguelike games, but -- alas -- I have yet to covert him.

Cheers,
Steven Black

22

Programming / Re: Resizing Terminal Screen

« on: August 27, 2012, 05:44:48 PM »

My own opinion falls directly counter to UglyTroll's.

Stupid/primative user interfaces are easy. Good ones are quite a bit of work.

The task is primarily about understanding the library. Open source libraries mean you can help out with documentation and examples. One shared stupidly simple example can fairly easily be looked over and corrected to become the canonical best example.

I have dicked around with just trying to get a decent user interface library to make a Roguelike for over a decade. Nothing fancy, just the core features I need to make the game I want. I wish LibTCOD had been around when I started (originally I was going to use C) I could have focused on extending it to do what I wanted instead of reinventing wheels.

This is actually one of the reasons that after ARRP I'm working on a comprehensive tutorial to create Roguelike games with my interface library. Good documentation and clear  examples are important.

Cheers,
Steven Black

23

Programming / Re: Resizing Terminal Screen

« on: August 27, 2012, 05:32:44 AM »

Does any small gui style console library for C/C++ exist? Other than curses or libtcod which both seem very intrusive, forcing to do stuff their way.

If you want to do things your own way the simple solution would be to use SDL to write your own simple console library. <http://www.libsdl.org/>

To get something simple shouldn't be a lot of work.

Cheers,
Steven Black

24

Programming / Re: Resizing Terminal Screen

« on: August 27, 2012, 05:25:00 AM »

I've given up on writing terminal-based games because the terminal emulators are generally crap and it's become the norm for terminal application developers to jump trough insane hoops to work-around lying terminal emulators and incomplete Terminfo data.

...snip-snip...

I wish you luck.

Thanks for the reply; sorry for my pretty late reply. :/  What do you (personally) do when you want a non-terminal based game that still has the "feel" of a terminal-based game?  What kind of languages do you use?

Thanks

Personally? I'm a fan of Python and PyGame. Of course, I'm a fan of Python 3 and PyGame's been slow to port from Python 2, so at one point I started a PythonTk terminal-like thing.

I've had problems restarting and changing interface libraries. I think at one point I started a similar project for PyGame before I decided Python 3 was so much better that I needed to migrate my code. The only problem with Python is that so much of the support library code hasn't been upgraded to Python 3.

At one time I was going to write a Roguelike in C. If I were to do that today and wanted a traditional interface, I'd just marry it with the PuTTY/MinTTY user-interface. You'd need a solution for Mac OS X, but doing that would get you Linux and Windows.

I've finally stopped churning my own codebase long enough that I have my own user-interface project. It's called Blacken and it is inspired by Curses. <https://code.google.com/p/blacken/> It's 100% Java.

In general, I hate Java. The only reason for anyone to program a Roguelike in Java is (1) they're straight out of university and that's what they were taught there, or (2) they have a day-job using Java.

I have a day-job using Java.

If I were doing a Roguelike in C today and wanted to concentrate on the Roguelike instead of all the boring user-interface stuff, I'd use LibTCOD.

Cheers,
Steven Black

25

Programming / Re: SVG fonts

« on: August 27, 2012, 05:08:04 AM »

I'd love to see more Roguelike games using SVG-based graphics instead of raster-based graphics.

Just remember that there may be environments where SVG-based fonts don't work but where SVG-based graphics still do work.

I've not looked at SVG fonts. In general, though, I'm a fan of SVG files.

Cheers,
Steven Black

26

Programming / Re: Copyright!

« on: August 07, 2012, 11:30:03 PM »

All I know the Tetris people went after the Curses-based Tetris clone now known as TINT (TINT is not Tetris).

I also know the DMCA is scary, and the copyright holders want new laws that are even worse. They're now trying to work things in to trade agreements so they can be invisible to the public until they're enforceable. I do not want to be involved in the first case brought about because of secret trade agreement or slipped in as a last minute amendment or some such crap... and that only seems absurd to the public because I'm such a small fry.

Add to that the proliferation of software patents and it's pretty easy for a game using artwork or names to find that it's violating a game-play patent on a game that was never released to the market... and that would have gone entirely unnoticed if the game hadn't otherwise been brought to their attention.

It looks like Jo may understand things better than I. My understanding is that if a small independent game gets hit with a patent suit -- a one-man game without a corporation behind it -- the individual developer is the one facing the lawyer bills even before folks know whether or not there are any grounds for it. If there are grounds for it (which you would never know because there are millions of software patents and most software violates dozens of them) then you can be charged per download and since you can't bankrupt a corporation you are left to bankrupt yourself.

Some people are comfortable playing with fire.

I just want to be left alone so I can play/develop roguelike games.

Cheers,
Steven Black

27

Programming / Re: Multiplayer in Roguelikes

« on: August 07, 2012, 10:49:48 PM »

There's a problem with async turns regardless of line-of-sight -- it ruins causality, which is a major component of any multiplayer game.

Take Player A and Player B, not in LOS.
Player A hits the Enemy on turn 1. Enemy flees.
Player B runs into the Enemy on turn 2. He throws a potion at Enemy, which happens to be a potion of gigantism. It lasts 10 turns. Player B and Enemy pillar dance for 8 turns.
In the meantime, Player A gets a cup of coffee, comes back and takes turn 2.
Player B hits the Enemy and it flees back to Player A on turn 11. According to B, Enemy has gigantism for 1 more turn. According to A, it's turn 3.
Now what?

It only ruins causality if you assume that one turn for player 1 is the same amount of game-time as player 2.

I'm saying that implication is flawed. One turn for me is not the same as one turn for you. Turns != Time.

If I'm not in the room with the other player, they could be in the middle of a Rest 1000 cycle. My character could be in the middle of a Rest 1000 cycle. It shouldn't matter.

Of course, it couldn't just be line-of-sight of other players, it needs to be line-of-sight of players or monsters that can see said player.

What it does do is ruin the possibility of having any concept of "game time" so any mechanic which relies on such a concept should really opt for something else -- like having the concept of time be tied to average player level.

Anyone who thinks you can't do real small-scale turn-based multiplayer has clearly never played Civilization with human opponents. Get yourself a copy of Freeciv <http://sourceforge.net/projects/freeciv/> (Mac, Linux, Windows) find yourself some friends and give it a go. By default it's true turn-based and if someone goes for tea, you're stuck waiting. (Though current versions of FreeCiv support 126 concurrent players, that is clearly overkill.)

With Civilization each player makes decisions at the same time. If you finish your turns at the same time there is no waiting for the other player. This approach should work for a Roguelike.

However, it's better if you only need to do this with the line-of-sight limitation I originally mentioned. If I'm playing with someone and that person needs to rest for 200 turns to heal and restore mana, I don't want to be on my own for that time. It's better if I just leave the room and when they come out they're all rested. (Though this has so many repercussions that I think the "rest to recover" logic needs dropped.)

As far as NPCs -- both friend and foe -- there would be two types: those that are only awake when in line-of-sight of players, and those that are like the players and can mysteriously know where the player is at and suddenly be within line-of-sight.

Being turn-based (even the variant where players do not take turns) should give you very much the same feel as a traditional Roguelike.

Being line-of-sight+turn-based would be a different sort of game. It requires a different concept of time.

The thing is... it's testable within the confines of a 7DRL. Not even multiplayer, as a simple single-player game. It breaks the simple "player goes" / "computer goes" logic that frequently drives simple Roguelikes. Will it feel all that different, though?

More importantly, will it feel more or less like a Roguelike when compared with a real-time game?

Cheers,
Steven Black

28

Programming / Re: A Roguelike TTF/OpenFont font: Is there interest in such a thing?

« on: July 27, 2012, 09:14:50 PM »

On Windows FontForge can be "tricky" to install.

I believe you are right. However, on Arch Linux it is enough to request fontforge package from repository and be done with it. Other Linux distributions probably do not make it any harder.

The only Linux distros that could possibly have hiccups would be RPM-based distros that require external third-party package repos to get a precompiled version. (I am not an RPM fan.)

This is a more laborious step for sure. From the poll results it seems we should stick to free licenses. Have any favorite fonts already?

DejaVu. It's Public Domain and has a reasonable initial set of monospace glyphs. It also looks good enough that folks actively use it in Roguelike projects.

There may be better-looking console/programming fonts. Better looking, more complete, and public domain? I think not.

There are very few reasons someone that favors an Apache or BSD license would disfavor a public domain license. Both allow embedding in commercial applications with closed-source modifications.

If we had a lot of GPL fans, we'd probably want something different. As it stands...

The other advantage of having our additions in the public domain: it's easy for other fixed-width fonts to steal them. If our primary goal is to get the missing glyphs in fonts, public domain aids that goal best.

Cheers,
Steven Black

29

Programming / Re: A Roguelike TTF/OpenFont font: Is there interest in such a thing?

« on: July 26, 2012, 12:04:14 PM »

I am busy with stuff until ARRP 2012 too but November looks like fine time to get involved. No idea how hard would be to start such a project but I am likely to at least look for right tools and try my hand at it. We shall see how it turns out.

The right tools are simple:

1. Inkscape (For single-glyph detail work in SVG)
2. FontForge (for actually editing fonts)

On Windows FontForge can be "tricky" to install. (It needs Cygwin and X.) While there is documentation on how to do it, for those with the system resources they could alternatively download a free virtual machine host and a Linux ISO image and be all set.

Worst case, it's a matter of spending time with the important glyphs in Inkscape. (Glyph compositing can be done in FontForge, so the e + ^ = ê stuff can skipped.)

Then it's a matter of picking the font (and license) to work from. Each font has a license you're bound to -- except public domain fonts can be derived and relicensed at will. A font with variable-width glyphs we want may be easier to adapt to fixed-width while retaining the same style.

That really should be about it. Some fonts have fancy build systems that can strip out glyphs or join them from multiple sources, but other fonts just use the TTF/OTF font file themselves as the only source. If I went with a dual-width font -- like some terminals support -- I would exclusively use such a build system.

Cheers,
Steven Black

30

Programming / Re: Multiplayer in Roguelikes

« on: July 25, 2012, 01:09:52 AM »

Personally, when I think "multiplayer roguelike" I don't think of an MMO. (Probably because I hate MMOs.)

My first thought is multiplayer like Civalization. It's turn-based. While each unit has few choices, each player controls a lot of units at the end.

So: a small group of friends play together.

Now consider: there is no actual requirement to keep the turns in sync across all players except when they're within line-of-sight. If I can't see you the difference of you going one turn or 10 to my one turn is meaningless.

So, when players are within line-of-sight, they need to wait for the other players to finish their turns. Talking to each other is still a free action, of course.

Next, more squelching of boring things.

If the group is moving as a unit, one player is given control and everybody moves as a single unit until enemies are encountered. This is simply squelching manual follow commands.

If a player is on auto-explore, their next command is handled automatically by the system so there is zero delay. If every one in the party is on auto-explore together, they should fan out, explore the map, then converge on the first monster found. (Given that talking is free and the first thing a person in their party would do is say, "Hey, there's something I need help with over here!")

So, yeah... the only time you should be waiting for other players is when you're near each other and monsters are around -- or you're near each other and playing non-cooperatively.

Then again, I see multiplayer as an extension of single-player multiple-character. We see those sorts of games in RPGs all the time, but they're rare with roguelikes.

Cheers,
Steven Black