31
Programming / Re: Breaking Items
« on: June 12, 2012, 08:27:51 PM »
"My wand of polymorph was in a terrible huff on Wednesday and would only turn things into pink ostriches, no matter how I begged and pleaded."
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.
32
Early Dev / Re: SnargleQuest, early days
« on: June 12, 2012, 08:16:12 PM »
This is coming along; the level layout engine is nearing what I'd call functional. Here's a nice recent example:
33
Traditional Roguelikes (Turn Based) / Re: Announcing Brogue v1.6.3
« on: June 08, 2012, 07:27:58 PM »
Glad to know pet salamanders are more viable now. 
34
Programming / Re: Game Flow Idea + Question
« on: March 27, 2012, 07:53:35 AM »I think it's important to think of what level of interactivity you want in the town. If you are going to allow the player to try to steal items from merchants for example, that process would seem a lot less compelling in a menu form where you click the steal button. If the player is able to recruit party members, it might be more interesting to see them walking around. The question is whether or not the act of exploring/interacting with the town is fun and interesting, or if it would be better to make the process fast, cut and dry in a menu. From my experience, walking around the town can be a very fun part of a game, especially if it is well designed and random enough to keep me entertained.
One way to go would be to embed mini-environments into the town, so you can walk around inside the tavern or whatever but you still get there via menu. The advantage here being that you can add new locations the player finds out about without having to fit (or have previously planned) a physical location for it into a map. One more level of alternation between hard and soft (and you could undoubtedly get into a menu inside the tavern, so there's another).
35
Programming / Re: Game Flow Idea + Question
« on: March 27, 2012, 05:26:02 AM »
Oh sure, I played Megaman. Interesting feature of that game is that although you're given freedom of choice, there is a "correct" order to beat the bosses in, so that you can use the best weapon against each boss. That probably wouldn't be considered a good feature in a modern RL; highly spoilable, and if you don't get spoiled you'll do a lot of retracing your steps as you figure it out.
I think gluing physical environments together with menus provides a lot of design flexibility. It's similar to the software engineering principle of alternating hard and soft layers. A menu is a soft layer because it's easy to fiddle with and change around, compared to a full environment you can walk around in and everything. That full environment, requiring a much greater investment of specificity, is a hard layer by comparison. That's where the meat is, of course, so it's not like you can do without it, but it pays to see where you can skip the investment because the payoff is too little and you can trade off for other advantages.
I think gluing physical environments together with menus provides a lot of design flexibility. It's similar to the software engineering principle of alternating hard and soft layers. A menu is a soft layer because it's easy to fiddle with and change around, compared to a full environment you can walk around in and everything. That full environment, requiring a much greater investment of specificity, is a hard layer by comparison. That's where the meat is, of course, so it's not like you can do without it, but it pays to see where you can skip the investment because the payoff is too little and you can trade off for other advantages.
36
Programming / Re: Game Flow Idea + Question
« on: March 25, 2012, 09:44:00 AM »
City-as-menu is actually something I'm doing in my current project; I'd never seen it done, and took my inspiration from the old BBS door game LORD (Legend of the Red Dragon). I wrote a blog post about it with a couple screenshots, but it's quite basic at this point (focusing for now on proving out the main technical bet of the project).
I'm undecided on whether I'll keep it this way in the final game, but it sure has advantages. It can be a lot easier to implement things quickly in a menu system, when you're just trying things out. And as a player, I always found it annoying to have to walk around the same town in the same way over and over just to resupply. There's no risk in town, hence it's not very interesting to walk around, so you might as well just give the players a button that puts them where they want to be (in a shop interface or whatever).
Multiple dungeons (which certainly occur in many RLs, though often via an overland map or the like) are also certainly on my slate, and here I find the abstractness of a menu system to be an advantage. The player can learn of a new location to travel to, and you can add it to the menu, without needing to explain away something like a new location on a map that wasn't there before. Some of my preferences here have to do with my particular goals for narrative experience in the game; your parameters will no doubt be different, but for me this is definitely a direction I'd like to see explored in more RLs.
I'm undecided on whether I'll keep it this way in the final game, but it sure has advantages. It can be a lot easier to implement things quickly in a menu system, when you're just trying things out. And as a player, I always found it annoying to have to walk around the same town in the same way over and over just to resupply. There's no risk in town, hence it's not very interesting to walk around, so you might as well just give the players a button that puts them where they want to be (in a shop interface or whatever).
Multiple dungeons (which certainly occur in many RLs, though often via an overland map or the like) are also certainly on my slate, and here I find the abstractness of a menu system to be an advantage. The player can learn of a new location to travel to, and you can add it to the menu, without needing to explain away something like a new location on a map that wasn't there before. Some of my preferences here have to do with my particular goals for narrative experience in the game; your parameters will no doubt be different, but for me this is definitely a direction I'd like to see explored in more RLs.
37
Programming / Re: dev blog for android roguelike
« on: March 16, 2012, 08:31:58 AM »
Don't forget tilt! That ought to be "popular."
38
Other Announcements / Re: Roguelike Radio podcast
« on: March 14, 2012, 12:04:10 AM »I'm having a lot of fun with my project. Makes me wonder why I ever quit coding in the first place. Maybe I just needed the break?
So no coding hell here. Coding bliss? That just sounds wrong....:-)
You, my friend, are in the Coding Zone. Relish it.
39
Temple of the Roguelike / Re: Welcome to Temple of the Roguelike Forums! (a.k.a. Introduce Yourself Thread)
« on: March 11, 2012, 08:36:09 PM »Welcome, Luke. I shall add Snarglequest to the list of actively developing roguelikes on the next pass.
Thanks! That'll help keep me motivated for sure.
Quote
Moria you say? Perhaps you heard about its variants maybe? I am kind of curious how popular was BOSS in the old days.
'fraid not; Angband was the next thing I found after Moria.
40
Programming / Re: Procedural generation of quests and narratives
« on: March 08, 2012, 09:54:44 AM »Besides being a fan of game design and the roguelike genre I like to write quite a bit. But for some reason I hate story driven games. It's part of what brings me to roguelikes in the first place. I get to create my own narrative.
Really, that's what I'm shooting for. I don't expect this approach to produce a story that stands well on its own; it's got to be something the player acts out and lives through. Doing it yourself adds so much compared to just reading something, and the participatory audience is much more forgiving of cliche and simplicity; the complexity is filled in by experience, inviting the player-creative narrative you mention.
Quote
However, science can solve everything. There have been some very good academic studies about story telling.
Indeed. I found some very interesting stuff last night on the morphology of folklore. You may yourself be interested to check out Propp's Morphology of the Folk Tale, which presents a more detailed outline he finds common to many archetypal tales. I found some tantalizing references to at least some initial forays into procedural generation based on this, but not much substantial. However, some of the referenced papers seem intriguing and I plan to take a look through them.
41
Programming / Re: Procedural generation of quests and narratives
« on: March 08, 2012, 08:49:50 AM »The hardest problem in designing a narrative on the fly is that many players aren't going to anticipate what is expected of them, no matter how many clues are given. The stereotypical MMORPG quests have become the norm precisely because they are almost impossible to fail outright: this has to do with their simplicity and avoidance of any real decision-making. If you want to design a good narrative, you'll need to design a whole slew of open-ended quests. This, all by itself, has some challenging considerations:
- To what extent do we allow the player to fail a given quest? The only "true failure" could be death, or it can relate to time, context, or a simple lack of power to prevent something from happening.
- Should a quest's failability depend on its gravity relative to the overarching goal? Making "important" quests harder to fail can be an abrupt change in the narrative: however, not pushing a player toward the goal may make them forever clueless as to its existance or solvability.
- How many different kinds of failure should be allowed? There are many shades of gray between "completing a quest" and "failing to complete anything related to the quest". Adding these shades, however, can complicate the narrative by a lot, and each case must be considered (especially as to whether or not it will ultimately aid or deter the player from the goal).
Yes, probably it's reasonable to assume we must allow for different kinds of failure, with different consequences. If the player fails the main quest in an obviously permanent way, that should arguably be a game-ender just as sure as permadeath. The thing to avoid would be letting the player fail, but go on a long time without realizing the game is in an unwinnable state. So if we're going to let the player keep playing, there must be some way forward (where there's life, there's hope!). Failures could be associated with an assortment of possible recovery strategies or alternate paths; since we can invent these dynamically, it should always remain possible to solve the dependency tree in some newly-invented way. Failure can thus become a source of new subquests, reducing this in large part to a matter of exposition.
Actually, there's another important kind of failure to consider, which you mentioned -- failure of the narrative to involve the player. If the player misses the wanted poster and the trail of blood and wanders off in a random direction instead, we need to decide if we're going to let that be, or if the story is going to go find the player. And why not just tell a different story at that point? Some subgraph of the dependency tree remains theoretical until it's been exposed to the player. Clear out the problematic sections and re-solve, and you've got a new adaptation of the story that's consistent with player actions. This kind of "ad-libbing" could be performed liberally to provide new opportunities to draw the player into the narrative.
Quote
I think one of the more interesting ways to apply a character narration without necessarily involving literal "go do this" is to have the game subtly change itself depending on the character's interactions with it. Wipe out a bunch of orcs? They'll probably put a bounty on your head. Save a princess from some bandits? I wouldn't be surprised if royal messengers start searching for you and asking for help.
Yes, I've had something a bit like this in mind for the constraint system that would be used to fill actors, props, and settings into various roles defined by "plot chunk" schemas. We might generate a potential scenario involving the role of a Trusted Ally, or an Old Rival, or what have you. Such characters could be introduced farther up in the dependency tree (earlier in the story) so as to be in place, and the characters themselves would have to make sense according to whatever's in the game ontology, faction rep being an excellent example. I'm imagining a bank of existing individuals alongside generators for instantiating new ones of different types as needed; what I'd like to accomplish is interesting crossovers, where characters reappear across plotlines but do so in meaningful ways.
42
Temple of the Roguelike / Re: Welcome to Temple of the Roguelike Forums! (a.k.a. Introduce Yourself Thread)
« on: March 07, 2012, 06:52:33 AM »
Greetings, rogues and roguelikes. My name is Luke and I've been into Roguelikes for quite some time. The first one I really played was Moria, around 1999 when I was in college; this led me into ZAngband, which I played quite a bit of (especially as a LostSoul). Later I spent some time with ToME (2 or 3, I forget... 2, probably) and ADOM. I was introduced to Dwarf Fortress by a game designer I worked with a couple years ago, and it really opened my eyes and got me thinking more broadly about the genre. Then when Dredmor came out, I saw again how much new ground there was to cover.
So, now I'm working on my own game. I'm working from scratch, since late last summer, so it'll still be a while before I've got a teaser alpha available; however, I'm keeping a pretty active development blog as a place to track my work and discuss design issues and such, not to mention hopefully garnering the interest of some potential players.
So, now I'm working on my own game. I'm working from scratch, since late last summer, so it'll still be a while before I've got a teaser alpha available; however, I'm keeping a pretty active development blog as a place to track my work and discuss design issues and such, not to mention hopefully garnering the interest of some potential players.
43
Programming / Re: starting a new rl as my graduation project
« on: March 07, 2012, 03:01:38 AM »
Right, if you want to work on AI in roguelikes just to work on AI, you might do better by focusing on AI-as-player, rather than just AI-as-Monster.
44
Programming / Procedural generation of quests and narratives
« on: March 07, 2012, 12:16:43 AM »
I'd like to get some discussion going on procedural generation of quests and other narrative-type content. This is something which figures heavily into my own game plans, so I've got some self-interest in bringing it up here, but I'd love to get some more input on all this and share some ideas generally. I've also laid out a little bit of this in one of my dev log entries, but I feel there's much more ground to cover.
Bluntly speaking, most of the quest content I've seen in games is pretty primitive, at least compared to other common narrative forms (books, movies, etc.). Even without procedural generation, designers are commonly guilty of subjecting players to endless FedEx quests, bounties, etc. The lame predictability of these simple tropes inhibits immersion and enjoyment. In the procedural space, it's understandable if ambitions have not tended to reach past this. After all, if it's hard to do by hand, it's harder still to automate, right? Perhaps that's fair; on the other hand, procedural generation has other attributes than being automated, and these may be of benefit.
As a particular example, procedural content generation systems have the benefit of being online; that is, you can keep generating new content as the player goes through the game. Nothing need be set in stone until it's been shown to the player. It's hard to relate this kind of freedom to anything experienced by a traditional designer. It's more like the position enjoyed by the Game Master of a pen-and-paper RPG, who may exercise constant, subtle discretion to the end of providing a (hopefully) satisfying player experience.
Every good Game Master knows how to ad lib; no matter how much you plan, the players will always surprise you. If the players start walking in the opposite direction from where the quest is "supposed" to be, a good GM will silently adapt the world around them so that it turns out they do wind up where the action is. By adaptively serving up a narrative that feels like it was carefully planned that way from the beginning, the GM provides the players with a feeling that's greater than just being inhabitants of a fantasy setting -- they're the heroes of the story, as it should be. The world conspires to draw them into their destiny. Nobody complains about this (unless it's too hammishly done, but you can get away with surprisingly much when you're willing to "cheat" behind the scenes); it's what we want and expect from a heroic tale.
In roguelike terms, the opposite of what we're talking about would be something like Dwarf Fortress. DF works incredibly hard to have a fully-operational fantasy world so that when you wander around in it, every little slice feels satisfying and real. But of course, most players will never see most of the content in that world. Most of the system is wasted, just to support the parts that you happen to wander through. True, it's just processor cycles, but the point is that if you can present a player experience without simulating the entire world, you can trim out a lot of fat. Moreover, you can gain a lot of control; DF can produce some entertaining narratives, but everything in the game is emergent and tied to the integrity of the world model. You'd be hard-pressed to shoehorn arbitrary structure into that world, in order to steer the player in a more focused direction.
So, can we conceive of a workable alternative model? Certainly, inroads are being made into online-adaptive PCG; a famous example being the "Director AI" in Left 4 Dead which models player experience in order to orchestrate pacing and challenge. I believe this principle can be extended much further, into the dynamic, online generation of epic-scale narratives carrying complex plot structure.
As I envision it, the system starts with some ultimate goal, derived from some suitable plot archetype -- Defeat the Evil Menace, Rescue the Princess, Free Our People, Lift the Curse, Find the Maguffin, etc. As with any good Ultimate Goal, it is of crucial importance but somehow indefinitely deferrable -- there can always be more impediments and side quests thrown in the way of success. So, we start from that ultimate goal and work backwards, determining what complications exist and setting up subgoals for them. Each subgoal can involve just as much complexity as the original goal, so in this way we can build up complex structures of interdependent subquests.
Rather than letting it explode infinitely, we would of course tune the generation to our specifications, depending on just how hairy we want to let things get. And, importantly, the only fixed points in the graph are those that have already been exposed to the player in some way; the rest is open to being tweaked or rewritten at any time, for any reason we may see fit.
There are major challenges to this approach, of course. First you've got to compose a suitably-large set of plot "chunks" and provide ways for them to fit together variously enough to provide novelty. Then you need to expose these structures to the player in some sensible fashion, which could be tricky in such a generic system. I think that for a more static form, such as written fiction, this approach would fail horribly. But in a roguelike, the player's involvement in the action fills in for a lot of verbiage, and I think an appropriate balance may be struck. Even accomplishing this, there's still the task of ensuring that what's generated isn't utter hogwash -- there must be some kind of semantic constraints on how you plug Actors and Props into Evil Plots, or you're going to wind up with the Princess kidnapping the Dragon, or being sent on a quest to retrieve the fabled Rusty Dagger of Worthlessness.
So, that's my wall of text. Any takers? Anyone know of other significant work in this area, or care to chime in with their own ideas on how to accomplish what I'm talking about?
Bluntly speaking, most of the quest content I've seen in games is pretty primitive, at least compared to other common narrative forms (books, movies, etc.). Even without procedural generation, designers are commonly guilty of subjecting players to endless FedEx quests, bounties, etc. The lame predictability of these simple tropes inhibits immersion and enjoyment. In the procedural space, it's understandable if ambitions have not tended to reach past this. After all, if it's hard to do by hand, it's harder still to automate, right? Perhaps that's fair; on the other hand, procedural generation has other attributes than being automated, and these may be of benefit.
As a particular example, procedural content generation systems have the benefit of being online; that is, you can keep generating new content as the player goes through the game. Nothing need be set in stone until it's been shown to the player. It's hard to relate this kind of freedom to anything experienced by a traditional designer. It's more like the position enjoyed by the Game Master of a pen-and-paper RPG, who may exercise constant, subtle discretion to the end of providing a (hopefully) satisfying player experience.
Every good Game Master knows how to ad lib; no matter how much you plan, the players will always surprise you. If the players start walking in the opposite direction from where the quest is "supposed" to be, a good GM will silently adapt the world around them so that it turns out they do wind up where the action is. By adaptively serving up a narrative that feels like it was carefully planned that way from the beginning, the GM provides the players with a feeling that's greater than just being inhabitants of a fantasy setting -- they're the heroes of the story, as it should be. The world conspires to draw them into their destiny. Nobody complains about this (unless it's too hammishly done, but you can get away with surprisingly much when you're willing to "cheat" behind the scenes); it's what we want and expect from a heroic tale.
In roguelike terms, the opposite of what we're talking about would be something like Dwarf Fortress. DF works incredibly hard to have a fully-operational fantasy world so that when you wander around in it, every little slice feels satisfying and real. But of course, most players will never see most of the content in that world. Most of the system is wasted, just to support the parts that you happen to wander through. True, it's just processor cycles, but the point is that if you can present a player experience without simulating the entire world, you can trim out a lot of fat. Moreover, you can gain a lot of control; DF can produce some entertaining narratives, but everything in the game is emergent and tied to the integrity of the world model. You'd be hard-pressed to shoehorn arbitrary structure into that world, in order to steer the player in a more focused direction.
So, can we conceive of a workable alternative model? Certainly, inroads are being made into online-adaptive PCG; a famous example being the "Director AI" in Left 4 Dead which models player experience in order to orchestrate pacing and challenge. I believe this principle can be extended much further, into the dynamic, online generation of epic-scale narratives carrying complex plot structure.
As I envision it, the system starts with some ultimate goal, derived from some suitable plot archetype -- Defeat the Evil Menace, Rescue the Princess, Free Our People, Lift the Curse, Find the Maguffin, etc. As with any good Ultimate Goal, it is of crucial importance but somehow indefinitely deferrable -- there can always be more impediments and side quests thrown in the way of success. So, we start from that ultimate goal and work backwards, determining what complications exist and setting up subgoals for them. Each subgoal can involve just as much complexity as the original goal, so in this way we can build up complex structures of interdependent subquests.
Rather than letting it explode infinitely, we would of course tune the generation to our specifications, depending on just how hairy we want to let things get. And, importantly, the only fixed points in the graph are those that have already been exposed to the player in some way; the rest is open to being tweaked or rewritten at any time, for any reason we may see fit.
There are major challenges to this approach, of course. First you've got to compose a suitably-large set of plot "chunks" and provide ways for them to fit together variously enough to provide novelty. Then you need to expose these structures to the player in some sensible fashion, which could be tricky in such a generic system. I think that for a more static form, such as written fiction, this approach would fail horribly. But in a roguelike, the player's involvement in the action fills in for a lot of verbiage, and I think an appropriate balance may be struck. Even accomplishing this, there's still the task of ensuring that what's generated isn't utter hogwash -- there must be some kind of semantic constraints on how you plug Actors and Props into Evil Plots, or you're going to wind up with the Princess kidnapping the Dragon, or being sent on a quest to retrieve the fabled Rusty Dagger of Worthlessness.
So, that's my wall of text. Any takers? Anyone know of other significant work in this area, or care to chime in with their own ideas on how to accomplish what I'm talking about?
45
Programming / Re: starting a new rl as my graduation project
« on: March 06, 2012, 10:28:19 PM »
For Roguelike AI, I recommend you check out the "AI" section of the Articles page on RogueBasin. I recommend in particular Brian Walker's essay, The Incredible Power of Dijkstra Maps.
As for the differences involved with doing a web-based roguelike rather than a traditional desktop application architecture, the main issue I'd expect to come up is object lifecycle management; unless the client is going to hold the entire game state in memory and never deal with save/load, you're going to have some server-side game state that outlives a single request. To me, this most obviously suggests a database back-end. You can keep the DB ops pretty simple, but you'll at least need basic persistence and lookup. Since your queries will likely be pretty basic, you might benefit from the simplicity of a NoSQL database (e.g. Mongo, CouchDB) -- just something to consider.
I've strongly considered putting together a web UI for my own game, since this would certainly aid in adoptability, but the architectural issues involved have dissuaded me thus far. Not because they're overly daunting (I'm plenty familiar with these architectures from my professional work, in and out of games), but because they'd distract from more fundamental directions of development. In that sense, it seems unfortunate to me that the effort involved in making your game work as a web app will inevitably take away time you could focus on the AI aspect, leaving your project somewhat less focused than it could be, but I guess it's all a question of what your priorities involve.
As for the differences involved with doing a web-based roguelike rather than a traditional desktop application architecture, the main issue I'd expect to come up is object lifecycle management; unless the client is going to hold the entire game state in memory and never deal with save/load, you're going to have some server-side game state that outlives a single request. To me, this most obviously suggests a database back-end. You can keep the DB ops pretty simple, but you'll at least need basic persistence and lookup. Since your queries will likely be pretty basic, you might benefit from the simplicity of a NoSQL database (e.g. Mongo, CouchDB) -- just something to consider.
I've strongly considered putting together a web UI for my own game, since this would certainly aid in adoptability, but the architectural issues involved have dissuaded me thus far. Not because they're overly daunting (I'm plenty familiar with these architectures from my professional work, in and out of games), but because they'd distract from more fundamental directions of development. In that sense, it seems unfortunate to me that the effort involved in making your game work as a web app will inevitably take away time you could focus on the AI aspect, leaving your project somewhat less focused than it could be, but I guess it's all a question of what your priorities involve.