Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - chooseusername

Pages: 1 ... 3 4 [5] 6 7 ... 22
So you basically took the algorithms from RogueBasin and started charging 75 bucks for them?

I played around with the demo of this thing, and at least 3 algorithms are prone to having disconnected areas. Way to go.
No-one is forced to buy it, and if it saves someone time, they might consider it good value.  Of course, that's a lot of money for what seems like little, and I'd be disappointed if I paid it and it turned out to give broken results.

People used to give away this sort of thing on a web page as a useless tool.

Other Announcements / Re: Nathan withdrew Interhack from sourceforge
« on: February 17, 2015, 09:48:52 PM »
A long time ago when this happened to a project I was interested in, I was able to find a slow updating mirror.  There was a tarball.sourceforge,net or something, and you could go to it, or one of it's mirrors, and find a snapshot of the last repo as of the night before or something.  Might still be a possibility, if you know the filename.

   Hello! I am considering trying to make a roguelike, but first, I need to produce a prototype to test gameplay. First, some details on unusual features I plan, in case certain engines aren't really designed for this:

   I want to try some unconventional things so I'm not just doing Yet Another Roguelike. This includes having a small party of allies (unsure whether they should be directly controlled or not, that's the sort of thing I need to test in rapid prototypes to see what works best) and a focus on 'missions' using partially or completely predesigned maps with much less focus on randomness, and the option to talk to some NPCs with diologue trees and such.

   With all that in mind, which engine/library would the community recommend? I've heard of Libtcod, T-Engine, and Ng, but I haven't finely examined them to know their limitations, and I'd hate to invest time in learning one only to learn that whichever one I started with can't support allied NPCs the way I want, for instance, or doesn't easily let me make custom maps. Also, there may be other choices I am unaware of. The prototype and the final game don't necessarily need to use the same engine, if one gets me started faster but limits my choices later, that's just fine for prototyping.
If your goal is to prototype, then I'd recommend going further.  Find an open source roguelike which you like the look of, and then prototype the features of choice on top of it.  Brogue, Incursion, various 7DRLs like Jeff Lait's Kobold, Orc and so forth.  You'll inherit a library with it, and have a chance to get into the library in the easiest way where you don't get caught on all the various things which  people find themselves asking for help and clarification on.

Brogue (C) has a intermediate layer, which abstracts curses and libtcod backends.  Incursion (C++) has an interface, which is implemented for curses and libtcod.  You could also look at Incursion as a game engine, where people can author modules based on the D20 AD&D rules and what not.  Although, apart from the original author's Hall of the Goblin King module which comes with it, no-one else has so far bothered - since it was only open sourced last year and it's been in a process of modernisation and post-publication clean-up.

What I liked about Jeff Lait's 7DRL games was that they felt like prototypes, where you could rotate the game view compass directions, and other things I can't remember.

I can't recommend anything I haven't used.

Design / Re: Scripting and storing level generation
« on: February 07, 2015, 01:08:31 AM »
Finally, if you're going to create a library, I would highly recommend doing it as an open source project.  The more people involved in contributing, testing, and using the library, the more robust and useful it will, most likely, become.
♫♫ Oh, what can it mean to a daydream believer ♫♫

It is questionable whether you will get any of these "more people".  Perhaps, once the project proves itself.  Perhaps not.  One thing you won't find is Omnivore giving monetary guarantees these people will turn up, or that they won't piss you around and waste your time and attention to the point you lose interest in the whole thing.

And if some do turn up?  More work for you.  People will contribute work and it will be buggy and flawed.  You will mention that the work is lacking and needs to be fixed, and the work will just sit there unfinished.  Then you'll spend time to finish that work and more often than not, you may as well have done it yourself from scratch to end up with something you'd otherwise be proud of.

And who supports the work contributed?  You do.  Someone contributes support for MacOS X and maybe some language.  Every person who encounters problems with shoddy work, or the bit rot that sets in as operating systems and installed packages change and vary, will likely complain to you.  You will be supporting compiling it with mingw, Visual Studio and so on if you want to get rid of this burden.  Or just ditch the code, and refuse to take any more unless other people are actively maintaining it.  *tumbleweed blows past*

It's easy to look at a successful project where this has all come together.  But there was likely many years on the road to that point, and lots of additional work you didn't want to be doing to get there.

When someone says if only you follow the true path and believe, you'll get 100 virgins in heaven, and you choose to believe - good luck!

Design / Re: Going beyond hack and slash
« on: February 02, 2015, 09:56:58 PM »
Good comment, Krice. I'll just stop limiting my thinking and remember that everything is possible. Good point about the Swedish guy. He showed us how to make roguelike games with roleplaying elements. Also that we have to stop limiting our thinking and remember that everything is possible.
Krice, if you named the Swedish guy and provided concrete details of how it was relevant and what he actually did, then it wouldn't be a somewhat random and unhelpfully vague statement which didn't really add anything.

Design / Re: Going beyond hack and slash
« on: February 02, 2015, 09:53:02 PM »
2 is as far as I can tell anecdotal and subjective.  There is after all no evidence that there is no evidence of interest in roguelikes that are not heavily combat oriented. .... and the avoidance of combat cannot exist without a reliance on combat.

This is a question of your standard of evidence. After all, there is no shortage of attempts at games, mostly so-called 7DRLs, that purport ..
I'll interject at this point and note that "attempts at games" is apples and oranges to "actual games".  As you suggest later, a 7DRL can only provide a casual and shallow gameplay experience at best, due to the limited time available.  If they do demonstrate alternatives, it proves nothing other than the existence of a fun casual gameplay well designed.

.. to be roguelikes and try to make things less combat oriented. As far as I can tell, none that fit the bill seem to have gained a nontrivial audience (say, on par with a top five angband variant) or spawned successor projects that have either. Maybe this says more about 7DRLs than anything else, you might argue. But it's also true that, as I mention above, Sil has been praised for its progress in the areas outlined by Omnivore. Yet Sil, as I understand it, cannot be won purely by slinking around avoiding combat and no variant has come along to challenge that situation, again calling the demand for less hack and slash roguelikes into question. The fact of the matter is that there's been plenty of opportunity for such a game to emerge and nothing seems to have happened. This is a reflection of demand.
No, your last sentence is arbitrary and not supported by your preceding argument.  I argue that it is a reflection on availability.

You can look at all the existing RPGs and roguelikes out there and even wider out into FPS and see that for all the worthwhile ones like Oblivion, Dragon Age, Baldur's Gate, etc etc combat is the crux.  It gives the meaning, the focus and is generally a shallow and achievable core mechanic.  And it is doable because it has been seen to be done.  Someone can just clone it and do minor iteration on it, and it is conceivable in their mind how to create it from scratch.  Conversely, there are no equivalent non-combat reliant games to clone and iterate.  Making a game from scratch is a tremendous investment of time and energy, but coming up with a new genre that is a superset rather than a subset of the combat-reliant standard, I argue is inconceivable to most.  If someone made it, and it was done well, it would be a breath of fresh air and in demand.

In order to support an argument of lack of demand, supply of quality goods needs to be disdained by the target market.

re: no avoidance of combat without combat, this seems to be the real issue. If there is no combat, it's not a roguelike anymore. If there is combat, the conventions of the genre lean heavily toward engaging and winning at it, not avoiding it. One radical approach would be to make it impossible to win in combat in the long run so that alternatives would be unavoidable, but the stable of models for this kind of thing is pretty thin. Stealth and pacification (e.g. crawl's Elyvilon) seem to be the only reasonably developed alternatives and from what I've seen only the stealth option seems very compelling.
I agree.  Combat is essential to a roguelike.  Even if one doesn't need to engage in combat, for the standard game world, it's presence lends a feeling of believability.  Stealth and pacification are merely decoration on the combat cake however.  Combat as an option gives value to other non-combat related choices that may rely on the inputs and outputs of others doing combat.

Challenges / Re: 7DRL Challenge for 2015?
« on: February 02, 2015, 09:31:43 PM »
On the other hand, it does justify participation in an event nominally about roguelikes that might (might) be of interest to roguelike enthusiasts...
I reckon a category system which doesn't count for points where games are declared roguelike, roguelite, not-roguelike.
I think that'd be great.  It'd be meaningless, but it'd be also interesting to see an aggregate opinion of where different games sit and who thinks they sit where.

Design / Re: Going beyond hack and slash
« on: February 01, 2015, 09:06:53 PM »
I find myself coming back to my original reaction here which is: 1.) No one advocating for a move away from "hack and slash" has very concrete ideas about how to make that workable, 2.) there's no evidence of interest in roguelikes that are not heavily combat oriented, and 3.) allusions to nethack manage to somehow be vague and narrow at the same time.
1 yes I am waiting for this as well.  Unfortunately, endless pointless forum discussions about vague things that one thinks would make one happy, is a lot more satisfying and accomplishable than doing whatever has to be done.

2 is as far as I can tell anecdotal and subjective.  There is after all no evidence that there is no evidence of interest in roguelikes that are not heavily combat oriented.

For me the show pony that comes to mind and illustrates the desire for alternatives to games defined by combat, is Deus Ex or Thief.  All the crying and wailing of joy that was made a big thing of, when people had several ways to avoid combat.  Or other paths to take.  That said, the value of those alternative ways was built on a large albatross being the fact that these games were pretty much a progression of combat to wade through from start to end, and the avoidance of combat cannot exist without a reliance on combat.

3 could be said to be an allegory for the meaning of the classifier roguelike.

Challenges / Re: 7DRL Challenge for 2015?
« on: January 28, 2015, 05:27:29 AM »

Are you involved with text-based gaming?  If so, whether your involvement is in mudding, roguelikes, interactive fiction, gamebooks, browser games or maybe even something else, please consider writing an article for Imaginary Realities.

Imaginary Realities is an online journal which originally ran from September 1998 to December 2001, primarily focused on mudding.  It has been revived, and had published a new issue just recently, which you can find here:

If you’re interested in the older issues, you can also find them here:

Find more details about suitable article topics here:

Please email me before writing an article, to confirm that the topic you are interested in writing about, is both suitable and within our range of coverage at this email address:

Articles should be in the range of 1000-4000 words, and need to be received by February 28th, 2015.  Longer articles are possible for serialisation, with approval required.

Design / Re: Going beyond hack and slash
« on: January 21, 2015, 07:29:43 PM »
You're right! I think mushroom patch should start a blog in which he devotes years to writing about how much he's not accomplishing.

+1 Great idea.  It would be so unique and original, it.. wait..

Ah well, I see there's some other guy that's been doing that for years and years.
Passive aggressive attacks on other forum members doesn't make for a healthy forum.

Design / Re: Going beyond hack and slash
« on: January 11, 2015, 11:34:38 PM »
And indeed, it would be interesting to create a roguelike-ish system for actual roleplaying with a DM controlling things at a higher level, players interacting in the usual verbal way, and the bookkeeping, map/board type stuff and calculations done by a server. But you'll never get much more out of the idea of doing "roleplaying" in a completely automated computer system than you see in games that are already out there. It's just not what computers do well.
Anyone care to outline what they imagine this game would look like / the game play experience would be?

Also, I'd like to push back at the idea that being more like a first person shooter is bad. Many of the best video games ever made have been first person shooters. At their best roguelikes can produce the kind of excitement of combat you see first person shooters, although in a more cerebral, less visceral kind of way. That is the strength of the genre, not puzzly minigames and wishing for Pinky Pie's party cannon.
You are basically constructing a straw man argument, by taking the discontent with combat and making a jump to first person shooters, and going from there.  Then you throw in some hyperbole and suggest combat is the core, and compare it against two more straw men you pull out of somewhere.

Less hyperbole and straw men please.

Design / Re: Going beyond hack and slash
« on: January 11, 2015, 06:18:27 PM »
Once upon a time, the combat system was a much smaller part of the game than it is today. If you look at Nethack (or even Omega), combat is a much smaller part of the game compared to modern roguelikes where the entire game revolves/around hack and slash combat.
Often, when I play games, I feel like combat is the tedious thing you do between the interesting bits.  Case in point is Anachronox (not a roguelike), where there's this awkward Japanese game inspired combat system.  It's prolonged and painful, and gets more prolonged and painful the longer the game goes on.  The worst part was that I saw a Matt Chat with the game designer, and if I recall correctly, the one thing he would have changed was to make the combat even more involved.  WTF!

The sad fact is that it takes a lot of time and effort to make a game.  It's a lot easier to cram in and pad out your game with lots of tedious combat, than it is to make a game full of content or gameplay that's interesting and worth playing instead.  If people are throwing tomatoes at you, you get tired of tomatoes.  If people are throwing handfuls of shit at you, you look forward to the odd tomato being thrown.  Does this mean that tomatoes can only truly be appreciated if the option is shit?  Or does it mean that the whole experience is lazily constructed to begin with?

Programming / 'PDCurses' versus 'PDCurses for "real" windows'
« on: January 10, 2015, 04:21:51 AM »
There's PDCurses, which is old.  And there's a new version which is confusingly entitled 'PDCurses for "real" windows', written by someone else which does something different - i.e. opens a window rather than using the DOS console.

Does anyone have any practical experience with them both?

Is the latter accessible by screen readers?

Programming / Colours and curses
« on: January 10, 2015, 04:19:53 AM »
I'm experimenting with porting Incursion to use curses, specifically PDCurses, which enables a DOS console on Windows to be used with the curses API.

One difficult to use part of the curses API, is the colour of characters, which uses a colour pair index.  Does anyone with experience using it have any good suggestions about how to use it to for dynamically encountered colour pairs?

As I do not know what colour pairs will be used, until the codebase tries to render them, this is somewhat difficult to set up in advance.  Perhaps also links to specific implementations of colour pair handling code which you know are not wastes of time?

Pages: 1 ... 3 4 [5] 6 7 ... 22