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 - Paul Jeffries

Pages: 1 2 3 [4] 5 6 ... 15
- Permadeath + Proc Gen combo
- The ability to experiment with different strategies and play-styles
- Every turn having important consequences
- Complex environmental interactions
- Interesting or novel takes on the basic formula

- The same old Tolkien-inspired Elves-Dwarves-Orcs fantasy setting for the bazillionth time
- When randomness vastly outweighs player decisions in determining success
- Zero-effort ASCII graphics (I don't mind ASCII when it's had some thought and effort put into it, but I think often its just used out of laziness)
- Difficulty curve feedback loops

Programming / Re: How big is your Level class/file?
« on: December 11, 2014, 07:46:04 PM »
I give this thread 100 out of a possible 10.

Temple of the Roguelike / Re: I miss the old RogueTemple theme
« on: December 05, 2014, 07:16:23 PM »
I think everything should stay exactly the way it is, including the fact that only super awesome cool people can have avatars.

Design / Re: Adaptive Difficulty
« on: November 24, 2014, 11:44:52 PM »
I really don't see anything that adaptive difficulty would give you that simply providing different difficulty modes wouldn't do a lot better.  If people just want to play for the experience then let them play on easy mode, if they are there for the challenge let them play on hard.  Why have the game constantly try to second-guess what the player wants when you could simply have them tell you?

Lots of games have treasure rooms with a special challenge inside or gollems or skeletons which are frozen but only attack if you mess with them, or tombstones... There's usually something you, as a player, can do to make the game more difficult if you want to.

While these can offer additional challenge, they also tend to reward you quite well with items that can improve your odds of winning overall, so I think usually it's more of a strategic short-term-risk for potential long-term-benefit kind of decision rather than simply an elective difficulty thing.

Challenges / Re: Procedural Jam has started
« on: November 18, 2014, 10:58:12 PM »
I entered.  I didn't make a roguelike but I did make a tool to generate pixel art tiles of various kinds, which hopefully should be useful for other Roguelike devs:

That sounds really cool! I wish there was something like that for creature tiles - like combining heads/torsos/arms :P

There's another entry that looks a bit like that (I haven't tried it out yet, though):

Challenges / Re: Procedural Jam has started
« on: November 17, 2014, 07:29:52 PM »
I entered.  I didn't make a roguelike but I did make a tool to generate pixel art tiles of various kinds, which hopefully should be useful for other Roguelike devs:

Player's Plaza / Re: Roguelike With Psionics?
« on: November 02, 2014, 04:12:37 PM »

I tried the cinematic mode but it didn't work; I just got a blank white rectangle appearing.  Not sure if that's your bug or Kongregate's!

On the game itself, I have some questions:

- I've noticed that the maximum amount of energy I can recharge slowly decreases over time.  What action actually causes that?  Is it intended as a counterbalance to spamming special abilities?
- The tooltip for the magic stat states that it increases the damage of magical attacks.  Does it have an effect on non-damaging magic as well?  i.e. will it make summons stronger or the healing spell more potent?

Good game, by the way - I'm enjoying it a lot!  The depth in the class system is particularly impressive.

Off-topic (Locked) / Re: Samsung's brilliant support
« on: October 21, 2014, 09:52:52 PM »
My Dell laptop horror story was when I bought a Studio 17 a couple of years ago.  It developed a crack on the hinge which I ignored because I assumed it was purely cosmetic.  Then, one day, my whole screen dropped off.  Turns out the only thing actually connecting the screen to the body of the laptop was a thin crappy bit of plastic casing, there was no internal pin.  So, once the crack reached a certain point there was no longer enough material there to support its own weight and both hinges failed at once.

That said, I now have a Dell Alienware laptop because I don't learn and I like flashy lights (plus I get a big discount buying Dells through work), which seems to be a lot better designed and more robust.  It weighs as much as a small car, though, so it should be.

This looks interesting.  I use VB.NET all the time at work; mainly for that reason I tend to avoid it for hobby stuff (since I'd rather learn something new) but as it's a very quick language to develop in I might consider using some of this stuff for a 7DRL or similar.

One suggestion I have to make your code more easily reusable for graphical roguelikes would be to have all of your classes implement the INotifyPropertyChanged interface to enable WPF databinding - if you do that then adding a graphical front-end would be almost trivial.

Are you aware of Rogue.NET?  They seem to have a similar sort of aim in mind so you guys might be able to help each other out.

Programming / Re: Loops on dungeon-type levels
« on: October 17, 2014, 10:45:56 PM »
Your dungeon generation algorithm sounds fairly similar to mine - I place a starting room and then recursively branch other rooms off of it in random directions.  Creating loops in that scheme is fairly simple, though; before placing a room I first check the size of the available space in that direction; if I find a suitable existing room while doing that then (assuming various other criteria are met) I connect the two.  I find that tends to work quite well and produce a reasonable number of loops and it sounds like it should be fairly compatible with what you're already doing.

Something I've been thinking about but haven't implemented yet is guaranteeing a start-end loop by initially placing the first set of branches into a predefined (but randomly-shaped) ring; once this initial loop is created the recursion unwinds through the already-placed rooms randomly adding extra branches to make the level more interesting.

It appears to be something to do with display scaling in Firefox; if I zoom out and zoom in again then it fixes it, at least temporarily.  Unfortunately when playing on Kongregate I have to zoom in because everything is so small.  I've switched to the Android version now which doesn't have the same problem, although it does seem to run fairly slowly on my 2nd Gen Nexus 7, which doesn't usually struggle with even quite graphically intensive games.

I've been playing this a bit and I really like it but I keep running into a weird bug where what is displayed on the screen doesn't seem to quite match the actual map; the enemy and player sprites seem slightly off-grid, walls aren't where they appear to be, pickups are actually in the tile next to where they are drawn and so on; such as in this screenshot where I'm fighting the dreaded Tree Bear:

This seems to happen quite frequently (every other level or so) and it's a bit game-breaking; I've been killed by ranged-attack enemies that could hit me but that the game wouldn't allow me to move next to.

I've also died a couple of times when enemies seem to suddenly get a flurry of five-or-so attacks in a row.  I'm not sure if that's a bug or just some sort of slowing effect; if the latter it should probably be made a bit more obvious that that's what is happening.

Design / Re: Damage reduction algorithm - looking for advice
« on: October 10, 2014, 06:11:09 PM »
I don't see any reason to reject the possibility out of hand as a matter of design.

Oh I completely agree; to be clear my whole point is that neither system should be rejected out of hand; as I said it's only personal preference that leads me towards the per-item system.  It has advantages (it's much easier to balance because of the smaller range of possible damage reduction factors, avoidance of risk-free combat and silly wardrobe choices, etc.) and disadvantages (greater complexity, built-in randomness, etc.) and you can only really judge the overall merit of any armour system within the context of a game design as a whole.

One thing to remember is that increases in randomness *always* are to the disadvantage of the player character. 

I broadly agree with this (indeed, the game I'm currently making has completely deterministic combat) but with the caveat that I don't think 'always to the disadvantage of the player character' necessarily equates to being always of disadvantage to the player's enjoyment.  I think that randomness has its place in the game designer's toolkit, even though it is often used badly.  For instance:

Armor protection is the same way.  The more randomness it leaves in the damage the player is taking, the less it matters to how the player will have to play and the player's odds of winning.

There's a flip-side to this, which is that if combat is very deterministic and you have high enough armour and/or HP that the enemy you're fighting can only do inconsequential damage to you each turn, the action you take next turn also doesn't matter that much because a 'bad' decision won't have any serious consequences.  Ideally, you want to avoid either extreme in order to keep the player's decisions meaningful.

Which is a major reason why I slightly shy away from cumulative damage reduction; the more armour you can stack up the less significant the consequences of being hit until, on a turn-by-turn basis, you don't really care that much whether you're getting hit or not.  To combat this the designer might introduce more powerful enemies which could easily one-shot a character without heavy armour, making unarmoured playstyles much less viable and the decision of what kind of armour to wear less interesting.  With a per-item system a full suit of plate-mail doesn't give you a maximum damage reduction any greater than just having the cuirass; adding extra pieces to the set just increases the odds of you getting that maximum damage reduction, so it's a question of managing vulnerabilities rather than just gaining a flat rate of damage reduction.  Your damage reduction range can be much less and so your potential damage range can also be less.  Of course, it's all a matter of balance and with care either system can be made to work successfully.

Design / Re: Damage reduction algorithm - looking for advice
« on: October 08, 2014, 08:48:59 PM »
The way that some games (I think POWDER, maybe some others) deal with this is to display your total cumulative armour score but when you get hit the game randomly determines which part of your body was struck and then uses only the armour value of the item you are wearing in the relevant slot.  This keeps damage reduction within a manageable range and if you think about it makes a lot more sense than the alternative; if somebody stabs you in the chest it's not going to make the slightest bit of difference that you're wearing a helmet as well as a breast plate.  The downside is that the AC rating shown to the player is a bit of an abstraction but higher numbers are still always better, so it's not super misleading.

I just want to put in a word against this interpretation of AC. AC is an average value which reflects overall difficulty of landing a damaging blow. The point is not that if someone tries to stab you in the heart when you're wearing a breastplate, they won't be able to stab your heart as hard once they've gotten through. The point is that stabbing through a breastplate is not a viable option in an active combat situation and an opponent must seek less straightforward alternatives, reducing their odds of landing a good hit, making it easier for you to avoid such hits, and on average reducing their deadliness. It is in this sense that wearing a helmet and a breastplate gives you a cumulative advantage.

The rock'em sock'em robot-like combat mechanics of D&D and roguelikes seems to encourage thinking that AC and HP are supposed to model combatants taking turns randomly flailing and pounding on each other with whatever's in their right hand until one's head comes off, but this isn't the right picture to have in mind.

Come on.  They're *both* wildly abstracted and completely unrealistic takes on real combat, you can't arbitrarily declare one of them 'right' and one of them 'wrong', especially since both systems model the cumulative advantage you're talking about - the only difference is that the system I mentioned models it on a per-body-part level.  Personally I prefer that way because it designs out the problem of heavily armoured characters only taking tiny amounts of damage per turn and therefore having tedious risk-free combat and also prevents the silly situation of characters striding around the dungeon with impunity wearing only their underpants and some really really good gloves.  But to each their own.

Pages: 1 2 3 [4] 5 6 ... 15