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

Pages: 1 2 3 [4]
46
Programming / Re: Simultaneous turns?
« on: March 06, 2012, 08:05:51 AM »
@requerent I like where you're going with the different phases of an action.  I could see this leading to a workable system based on rock-paper-scissor type resolution rules for attacker/defender state pairings.  If you choose a strategy that assumes you're faster than your opponent, such as exposing yourself briefly to make a quick, opportunistic strike, this can work out fine if you are in fact faster.  But if your opponent is faster, and seizes the advantage, you'll be attacked while exposed and suffer greater harm.  Similarly, if you suspect you're slower, you could play more conservatively (to avoid embarrassment and failure), deflecting your opponent's blow before striking back while he's off-balance.  The strategies chosen would determine what state each combatant is in at each phase within the turn, and resolution rules describe tactically significant game outcomes.

47
Other Announcements / Re: Share your ideas for 7DRL
« on: March 05, 2012, 07:14:59 PM »
Idea #1: Rogue Like Hell (or, "Roguelike your Life Depended on It").
The dungeon is dark.  The monsters are deadly.  WAY TOO DEADLY.  You are not a hero.  You're a lost fool with a scant few tricks, running for your life amid the horrors, hoping to find the light.  You have no aspirations of glory.  The day is too dark, the monsters too vicious.  You might, might slay a scant few of them in desparation, but clearing dungeon levels is out of the question.  Your tools are more focused on stealth and tactical manipulation (shoving enemies, tripping them, short-range teleport of self and others, closing and locking doors behind you, etc.).  Basically, you spend the entire game on the run from overwhelming forces at your heels, trying to eke out just enough advantage to stay ahead of the hordes of darkness.

Idea #2: Dungeon Sabateur
This idea is based on an old DOS game I played back in the day, called Pyro 2.  It consisted of randomly-generated levels representing floors in buildings you were supposed to destroy.  Scattered around each level were various gas canisters, which would start spreading out as you walked past them.  The player trailed a lit fuse behind, and you had to try to set off as big a fire as possible without burning yourself alive.  The original game certainly had important roguelike aspects -- random level generation and permadeath -- but I think there's room for a re-exploration of these ideas in fun new destructive ways (molotov cocktails, anyone?).

48
Early Dev / SnargleQuest, early days
« on: March 01, 2012, 10:34:35 PM »
I'm developing a new roguelike from scratch in C++, working title SnargleQuest.  My primary focus with this project (my first roguelike, though I've done professional game development in the past) is to advance the state of the art for meaningful structure in procedurally generated content.

Specifically, I'm implementing a system that builds dungeon levels bottom-up from a particular specified structure (expressed as a graph, using the Boost Graph Library).  So, for example, you could have a level that contains a boss and two minibosses, and the connectivity of the rooms will force you to go through the minibosses' areas first in order to reach the boss, rather than allowing any paths that go around them.

Or, similarly, I'm planning to do lock-and-key puzzles of arbitrary complexity.  E.g., the red key unlocks the red door, behind which you find the orange key for the orange door, etc.  Having the room structure as a graph (and with BGL as a rich tool for working with it) means the system can set up really complex puzzle layouts while still guaranteeing that they are solvable.

The other area of PCG I'm hoping to improve on is storyline.  I'm working on a system that abstracts the notion of a basic "mad libs" style quest by allowing whole structural pieces to plug in to each other, rather than just filling out a single flat template.  The branching possibilities implied here should result in a wide gamut of possible content; the main challenge I see is in constraining it all to be sensible.

I've started a dev blog for the project, as a diary for myself and to garner interest and commentary from friends and community.  I'd very much appreciate the attention of anyone who cares to discuss these ideas, or would be interested in playtesting once I get to that point (not yet, but progress lately has been solid).  The blog is at http://snarglequest.blogspot.com/.

In order to take good advantage of the generic systems I'm putting in, I need to come up with a lot of different kinds of content that are enabled by this approach -- I need more examples than lock-and-key puzzles and pinch-point rooms containing monsters you're supposed to fight.  As I flesh out the procedural narrative ideas more, I expect to derive a lot of the environment structure from the plot structure, but I think it'll be good to have a large selection of stuff that occurs in non-plot-driven environments as well.  So, I'm open to suggestions.

49
Programming / Re: Java Roguelike Tutorials?
« on: February 24, 2012, 12:01:48 AM »
If you're a novice program experiencing problems with flickering, I wonder if perhaps your game is not doing double buffering.  Read up on that topic to make sure you understand it; whether or not it's the problem here, it's definitely something you should know about if you're doing game development.

50
Programming / Re: Modeling Armor in Roguelikes
« on: February 23, 2012, 11:59:39 PM »
In my system, a strike has a degree of success, which is used in determining the severity of the wound.  Armor reduces this degree of success (with some variability, to avoid risk-free or too-predictable situations), so any strike that gets through the armor is attenuated in proportion to the efficacy of the armor.

Pages: 1 2 3 [4]