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 - TSMI

Pages: 1 2 3 [4] 5
46
Programming / Re: rl oriented scripting language features.
« on: June 24, 2011, 01:16:07 AM »
For my own endeavors I've quite often considered integrating a Scheme ( its another language I occasionally dabble with ) for scripting purposes, but it always comes back to what I mentioned in my previous post in that it doesn't seem to buy me anything in terms of roguelike dev. I think its the mental gear change when switching from c++ I find too much, especially given how expressive c++ is anyway :)

I have too - scheme can buy you loads IMO, once you know how to get some power from it.

It may interest you to know that Guile, which was designed to embedded, has finally reached version 2.0, and is appareantly much improved.

47
Programming / Re: rl oriented scripting language features.
« on: June 23, 2011, 01:22:39 AM »
What do you mean by scripting language? A very high level, dynamically typed language that has an intrepeter?

I've always found the term confusing - what's "scripting" and what's "programming"?

48
Programming / Re: Handling deaths/corpses
« on: June 11, 2011, 01:11:30 AM »
I was thinking of handling corpses by adding a special inventory slot that's set when the creature's created -- Nothing for some, corpses for others -- that doesn't effect and usually isn't affected by anything else until the creature dies, at which point it's dropped just like any other inventory slot.

That sounds like e a nice solution...just make sure it's hidden and you can't drop your own corpse :D

49
Classic Roguelikes / Re: Legerdemain - A major roguelike, right?!
« on: June 08, 2011, 06:45:48 AM »
Now you're just being obtuse. I've said all I have to say anyway - I'll let you get the last word in.

50
Classic Roguelikes / Re: Legerdemain - A major roguelike, right?!
« on: June 07, 2011, 09:13:16 PM »
So that's 6/9. If you can't concede that LegerDeMain is *at least* a Roguelike-like, then you're engaging in some kind of weird restrictive purism that doesn't interest me or most players.
The Berlin Interpretation lists your defining qualities about the Roguelike genre. You accept that definition without offering any reason that it should be accepted instead of mine. It is on the Wiki, so it must be true!

You are one weirdo on the internet with a definition of roguelike. As I understand it, the Berlin Interpretation was an IRL meeting of several weirdoes on the internet reaching a comprehensive consensus on a definition of a roguelike. True, it's not exactly a stone tablet handed down from the Gods. But it is a well written, clear, consensus based definition, and it definitely trumps one persons definition of a couple of lines in a forum discussion.

And no it's not mine. I had no part in it, and I disagree with bits of it.

Also, how many "like"s are you willing to slap on stuff just to keep the word "rogue"? I do not get it. This genre does not make games in any way more legitimate.

I don't think excluding games like LDM or any other game that isn't a textbook roguelike, from discussions about roguelikes, is of any purpose at all.

51
Classic Roguelikes / Re: Legerdemain - A major roguelike, right?!
« on: June 07, 2011, 04:43:07 AM »
When I have been trying Legerdemain, I got to the pub, and then the overarching story was like "try to go somewhere, if you are not killed then return to the pub and go somewhere else, or the same place to hunt in this easy place again, if you are kiled (as you usually are) then awaken in the pub and try again or go look for an easier place". IMO that really loses the roguelike feeling.

If you replace "pub" with "character creation screen" it pretty much exactly describes a typical ADOM game for me:D

But yeah, the game would be even better if the dungeons were generated procedurally each time you load a save or something.

52
Classic Roguelikes / Re: Legerdemain - A major roguelike, right?!
« on: June 07, 2011, 04:21:39 AM »
The only thing not Roguelikeish about Legerdemain is the lack of randomly generated levels. Everything else is there.
Except the permadeath. Randomness and permadeath are two defining qualities about the Roguelike genre. It is just an RPG without them.

No, those are your two defining qualities about the roguelike genre. Wasn't a concensus reached with this?

http://roguebasin.roguelikedevelopment.org/mediawiki/index.php?title=Berlin_Interpretation

So going through the high value factors for Legerdemain...

Random environment generation
Partial (randomly placed items and monsters)

Permadeath
No, even though the fact that places to save are so few and so far away from the areas you're likely to die that it feels very close to it.

Turn-based
Yes

Grid-based
Yes

Non-Modal
Yes, even though the scale outside of towns seems to change, the game play is exactly the same.

Complexity
Yes.

Resource management
Yes

Hack 'n' Slash
Partial - the NPC interaction elements are very important but the vast majority of the living things you meet are monsters to be killed.

Exploration and discovery
No. Difficult decision, because the dungeons have the same layout every game, even if exploring them is very important.

So that's 6/9. If you can't concede that LegerDeMain is *at least* a Roguelike-like, then you're engaging in some kind of weird restrictive purism that doesn't interest me or most players.

53
Programming / Re: Handling deaths/corpses
« on: June 02, 2011, 09:58:41 AM »
That looks very similar to a mixin.

http://en.wikipedia.org/wiki/Mixin

I wouldn't have thought of doing it that way in C++, it's surprisingly clean.

54
Programming / Re: Handling deaths/corpses
« on: June 02, 2011, 01:54:25 AM »
The basic class-like unit is a methplex. Classes of monsters, items, spells, etc. are all methplices. A methplex is a collection of methods, but it can also do some augmentation (applying some methplex with some parameters to some object). It can also be refreshed, which means that all descendant methplices arising from augmentation are killed and augmentation is performed again, this happens when e.g. you wear or remove the ring of strength.

This sounds some what similar to using mixins in ruby. In ruby a module is something between a C++ namespace and a class... on a basic level it's just a convenient way to group related methods, but they can also have state and instance variables, and if you "mixin" a module into a class, you automatically get all the methods a module has.

Though your idea is a bit beyond me:D

55
Other Announcements / Is anyone here blind or semi-blind?
« on: June 02, 2011, 01:48:48 AM »
I was thinking today that turn-based, text-graphic roguelikes would be the sort of game that'd be easier to make a nice blind-interface for. I had a quick google around for blind friendly roguelikes and I could only find one, written by a commercial company at http://www.blind-games.com/.

So I was wondering...does anyone here have some degree of blindness and play roguelikes?

56
Programming / Re: Handling deaths/corpses
« on: June 02, 2011, 01:44:49 AM »
C++ is a bit better in this, since you have virtual base classes and multiple inheritance, which can be successfully used for this purpose. But these features are rather counter-intuitive

If you want to go that way, why not create a tree of inheritance that doesn't require multiple inheritance? Anyway, inheritance like that usually becomes kind of complex so why not just handle it with data-driven design.

I've seen you mention data-driven design a lot. Would you care to give an example of contrasting it with C++ style OOP? (Yeah I could google but I want something roguelike specific)

57
Programming / Re: New project?
« on: June 01, 2011, 01:34:37 AM »
I'd love it if someone gave the old class Omega a less suicide inducing user interface.

http://www.alcyone.com/max/projects/omega/

58
Programming / Re: My 3D Rougelike
« on: June 01, 2011, 01:27:57 AM »
OP is your name by any chance from that "Mr. Lizard" sketch on.. Jam I think it was? If so - LOL, I absolutely love that one.

59
Programming / Re: Handling deaths/corpses
« on: June 01, 2011, 01:25:29 AM »
In what world are the bastardised hybrids of java and C++ traditional OOP languages? :P They're both C-likes with a limited OO layer tacked on.
The same applies to other class-based OO languages, like Simula or SmallTalk.

Of course all can be solved, but naive OO does not provide tools to do that.

Quote
Instead of changing the class of an object (which is impossible), I think it'd be better to haeve a method in monster, "die", that returns an item object (ie a corpse). You can then call the destructor itself or wait for the GC to pick it up.

Now suppose you want to have a Resurrection or Animate Dead spell, and the properties of the animated corpse to be based on the properties of the original dead monster. Then you should copy all the properties of the original monster to the corpse, and after that, properties of the corpse should be copied to the new monster again. Too much duplication for my taste. Also all pointers/links to the old object become invalid instead of pointing to the new one (for some reason IVAN creates a new object when you fix or break a weapon, which makes you lose all the experience with the given weapon if it is broken and fixed, which is weird). Monster death is one of the cases when an object changes into something else, you can also have a polymorph spell or something like that.

IVAN is object oriented, but I do not like the design of it (as it is both object oriented and data driven, which means that both the C++ source and the script defining objects contain definitions of the classes... not nice IMO).

Quote
Quote
objects that share properties of several classes

In java it'd be better to turn "several classes" into "several interfaces" then there isn't much issue (but here I admit my ignorance of C++)

So let's take a typical example: we have a Creature class, and the following derived classes:

Humanoid (can wield weapons and wear armor)
Equine (can be saddled and wear horseshoes)
Bird (can fly)

Now, you also want to have Centaurs, Angels, and Pegasi. They share properties of several of these classes. AFAIK Java interfaces do not help here, since they just inform the compiler that a given class of objects implements some methods, but it is impossible to share the implementation, or to know whether a given Creature object is flying (or maybe it is possible, but then I think we are using the interface feature not in the way it was designed for).

C++ is a bit better in this, since you have virtual base classes and multiple inheritance, which can be successfully used for this purpose. But these features are rather counter-intuitive (that's why they did not make it into Java), and I still expect some problems when you are e.g. trying to save a file.

Quote
objects that change properties of other objects

Let's assume you have somehow successfully managed to include Humanoids, Equines, and Birds in your game. Birds can fly and Humanoids and Equines cannot. Now you want to add winged armors and horseshoes of flying, which allow Humanoids and Equines to fly too. You also want to add the Spell of Gravity which disables the birds' fly ability.

The problem is that in roguelikes objects do not form a strict hierarchy of classes, with properties depending on the class of the given object, but rather may be changed by the environment. (Of course not all roguelikes.)


Those are some good points...I won't try and defend java anymore since I don't know it well and it doesn't seem to click with how I think.

My OO language of choice is ruby, in which mixins will solve a lot of those problems (or at least make them easier to deal with) - modules can be used like "filled in interfaces" which is very handy.

I'm curious, do you have a preferred paradigm when doing these things? Or are you simply pointing out that class hierarchies aren't the silver-bullet?

60
Programming / Re: Handling deaths/corpses
« on: May 30, 2011, 11:15:15 PM »
For me, problems like this are an argument that the traditional object oriented programming (like in Java/C++) is not suited that well for roguelike programming. Objects that change classes during gameplay, objects that share properties of several classes, objects that change properties of other objects... and so on.


In what world are the bastardised hybrids of java and C++ traditional OOP languages? :P They're both C-likes with a limited OO layer tacked on.

Anyway, even in those languages I don't think the above are much issues.

Quote
Objects that change classes during gameplay

Instead of changing the class of an object (which is impossible), I think it'd be better to haeve a method in monster, "die", that returns an item object (ie a corpse). You can then call the destructor itself or wait for the GC to pick it up.

Quote
objects that share properties of several classes

In java it'd be better to turn "several classes" into "several interfaces" then there isn't much issue (but here I admit my ignorance of C++)

Quote
objects that change properties of other objects

Not seeing a problem here either...what's so bad about having a method of an object operate on another object? no worse than having a function operate on a struct/record surely?

Pages: 1 2 3 [4] 5