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

Pages: [1]
1
Design / Re: Quack Potions
« on: March 03, 2015, 02:33:55 PM »
This potion idea is great and I think some comments reveal that people are just jealous they didn't come up with this idea themselves.

Thanks :)

Quote from: mushroom patch
These mechanics are obsolete, and we must move beyond them! Time and tide wait for no man!
Out with the old and in with the new!
For every step forward, there must also be a step backward. This isn't a simple, "Oh, now that I have this +3 shortsword, I can drop this +0 short sword!" change here. There's a reason vinyl is making a comeback: analog recording has certain capabilities that digital recording doesn't. The hunger clock works badly in Angband because it's just a hard limit on how long you can stay underground, which is already covered by torches and consumables.

Regarding OP, I like the idea. I'd need to try it to see how it would play out, but it really seems like a clever and interesting mechanic. Just make sure the low-quality potions are useful as something other than just vendor trash.

True, all of these mechanics really depend on the whole ecosystem and it is in my opinion difficult to rate them on their own.
The idea I'm running with now is to make consumables quite valuable on their own right, but I'll have to see how that impacts the game.
<< I was about to say that I hope to have an alpha version available in a couple of months, but I know how it goes so I'll not say it ;). >>

Some mechanics really are better than others, though, and sometimes people discover better solutions to existing design problems.  This just isn't one of those times

You have given well thought-out reasons why you like the current ID system (if well implemented). I haven't really gone into that discussion because I'm
slightly ambivalent about it. I guess my biggest problem with it is that, at-least with the implementations I've seen, the ID game is mostly a system for low to medium
level play and does not really affect the later game because you either have identified everything or there are few options left.

I might have missed it, but I don't think I've seen you argue specifically against my proposal but rather in favour of the ID system.
Could you tell me why this doesn't appeal to you?

2
Design / Re: Quack Potions
« on: February 27, 2015, 05:43:42 PM »
Quote
But what's wrong with making ID'ing automatic/easy for lower-level items and make it difficult for high-level stuff? The ID'ing process would be infrequent, and therefore could be more involved and meaningful.

That is actually a very good idea. I was planning to ID artefacts anyway, but yes, I could use something like that.

3
Incubator / Re: Alpha development: Ganymede Gate
« on: February 27, 2015, 04:58:05 PM »
It looks nice, though it took me a second to realise it wasn't turn based ;).

The first time I ticked up  a laser pistoel but could not equip it. At that time I also could exit the inventory but that was just me being stupid. ( exits the inventory).
The gatling laser is quite enjoyable :).

I would like to have an examine command though to look what the red gasses are (I expect flames or something).

It is fun thought a bit hectic.

4
Design / Re: Quack Potions
« on: February 26, 2015, 04:37:27 PM »
I do not like that idea.

There's been a trend against identification subgames in various of the larger projects, notably angband and dcss, and the reductions have resulted in cleaner, better games. The lesson is this: Identification subgames are lame and should be avoided in new games. It's not that you should try to replace it with something else.

The lesson is that crawl and angband had bad ID systems and didn't know how to make them work

I think this sums up the general feeling of the identification subgame quite well :).
Personally I like it, but I think it is a shame that it only matter for the first part of many games. After that you can have a good deduction of what unidentified stuff is and if it is worth using it.

That and I think is will be easier to implement ;).

Vanguard, could you explain to me why those games had a bad implementation?


Deciding not to do it based off various opinions (especially ones from people who try to portray their preference as the only proven workable solution without much substantiation) here may be a big mistake, or it may not.  You won't know until you try it.

Oh, for sure.
But there is also a good chance that somebody would come up with a reason why my idea is very bad and I should not even bother, or maybe tweak it so it becomes better. But you are correct that if there is no implementation quite like it we won't know. That and the game itself probably influences a lot of how the subgame works.

I would like to point out your idea is less about IDing and more about introducing risk/reward. Kind of reminds of decks from DCSS, but the positive effect is a little more straightforward. Unknown risk, known reward? So I kind of like it.

Instead of "I'm in a bad situation, let me chug this on the off chance it helps me somehow" the thought process is more like "I'm low on health. I really need a health potion, but if I use the low quality one I could get get a bad status.... or I could use my high quality health potion but I only have 1 swig of that, maybe I should save it."

[edit: Actually, this is more similar to decks than I thought. You can use scroll of identify to see the next effect. I wouldn't know, since I never really use them.]

Exactly.
Instead of the sense of wonder rogue was trying to implement, it is indeed an risk - reward system. One that I hope will
stay relevant until the endgame.

I did not know about those decks, I will look them up. Thanks!

I was first thinking of not having healing items, only providing healing at set points, to invoke the gritty feeling of the setting. But with this I think that providing some healing will still preserve that feel due to the risk of taking them.

5
Design / Re: Quack Potions
« on: February 24, 2015, 07:59:04 PM »
I was thinking of having different quality of items. This is easy for weapons and armour, the basic +1 etc.
But for potions this could be the difference. Higher quality items have a smaller chance of side effects.

Off-course, the normal way of stacking items (a simple counter) wouldn't work any more because each
potion is different. Not something the player should notice however.

6
Design / Quack Potions
« on: February 24, 2015, 04:20:16 PM »
Hey there.

I'm making a roguelike based on the Warhammer Fantasy Roleplay systems, a gritty , low-magic setting.

When researching about the identification sub-game, and a lot of people don't really like it or think it is often badly implemented.

Now, one of the things in WFRP2 was that certain potions could have side effects or wouldn't work at all. What if instead of having
to identify potions, the game would assign a random side effect to the potion. This could be a good effect, a bad effect or no effect
at all, maybe even depending on the quality of the potion. In addition, a potion would provide a couple of sips instead of just one.

Thus the first draught of healing would have no additional effect, while the second would drain your stats for a while, while a
potion of poison would have a minor curing effect as side-effect.

Finally, you could have a skill as Apothecary for example which would have a chance of identifying the side-effect of the potion before use.

Do you guys like this idea, and what would some caveats be, and are there examples of rogue-likes where something like this has already been done?

7
Programming / Re: targetting line
« on: March 27, 2014, 02:29:19 PM »
Thank you very much. It works now.

I especially like your trick of using Elios' line as an intermediate.

Thanks again!

8
Traditional Roguelikes (Turn-based) / warp rogue source
« on: March 26, 2014, 09:45:05 PM »
Heya,

I am trying to find the source code of warp rogue. I know I had it once upon a
time, but now it seems it disapeared from the internet. Anyone who happens to
have it catching dust?

Luctius

9
Programming / Re: targetting line
« on: March 26, 2014, 08:12:27 PM »
Thank you very much, that is exactly what I am looking for.

Elias sounds promising. I found  Wu's line algorithm, but my google-fu
failed to find anything about Elias (except for your web page ;) ).

Could you perhaps point me to some more documentation about Elias' Algorithm?

10
Programming / targetting line
« on: March 26, 2014, 12:56:59 PM »
Hello all,

I'm creating a roguelike (as are we all I guess), which will have a lot of range combat.
Thing is, I'm trying to create a targeting line / projectile path, which seems pretty simple,
and I'm getting stuck creating one which matches the fov strategies.

The problem is, given a fov algorithm all the points in sight should be target-able. However
if I'm using Bresenham's algorithm, creating a line from a to b might fail due to obstacles,
but the line to c does go through point b.

Any suggestions on how to create such a targeting line.

For example:
The fov code finds B (anc C) from @, but my los does not.

Code: [Select]
@ . . . . . . . . .
 . . . ### B . . C

The reason I'm trying this approach is because I'm fiddling with different fov
strategies and not all of them provide an easy method of los. So my idea is
to give the fov code precedence in deciding if something is target-able, by
how do I extract  a nice projectile path out of it.

I have also looked at the digital lines strategy suggested at roguebasin,
but I do not have a good feeling how I should implement that. Any
suggestions on that would also be welcome.

Maybe I'm using a completely wrong approach here, but Im pretty stuck :S.

I am using plain old C, and am fiddling with both libfov and the digital fov
code used in kusumo.

Edit:
What I have now, is I use the los code of the digital fov, check which grid spaces
are touched, and then back-trace to get the targeting line suitable for that fov.
However, knowing that is can be seen, it seems like a lot of code to get the
targeting line...

Pages: [1]