Messages

1

Development Process & non-technical / Re: Plans for 2014

« on: January 13, 2014, 02:08:11 AM »

I've temporarily pruned my game project down to a game library project, which I hope to have in a working state in time for next year's 7DRL.  If it is, I'll do a 7DRL based on it as a sort of demo for the library.

The library is going to be called Graphlike, and will provide capabilities for procedural level generation based on a higher-level abstract representation of the level as a planar graph.  If I can ever get my algorithms sorted (ha), I believe this will represent a useful advancement in roguelike science, and provide a useful starting point for much experimentation.

I've been cracking at this off and on for a bit, and several approaches have gone out the window, but I'm currently going slow-and-steady on one I think will work fine once I've gotten through the slog of it.  Guess we'll see!

2

Programming / Re: Monster generation

« on: January 13, 2014, 01:52:13 AM »

Depends so much on what results you want.  Do you want a completely random mix of monsters on each level?  Or should levels be a bit thematic, or choose a few kinds of monster to emphasize (lots of orcs on this level, lots of jellies on the next, etc.), with a few wildcards in the mix (there could always be a greater demon around the corner)?

In any scheme, you're probably going to be starting with some metric for how difficult a monster is.  One common way is to specify the "native level" of the monster.  On level 7, you should see lots of level 7 monsters, as well as some level 6/8 monsters, fewer 5/9s, etc. until you hit the point where you feel like it's too unreasonably out of depth.  Let's say you make half your monsters same-depth, and divide the remaining half between deeper and shallower.  For each of those cases, maybe give it an 80% probability of being one level out of depth.  The other 20% of the time, give it an 80% probability to be two levels out of depth, etc.  Exponentiate like that until you hit a limit, and just cut it off there.

So, that's a reasonable way to go, but it doesn't treat monsters any differently.  If that's not what you want, you might think about spawning packs of monsters as a unit or other things like that.

3

Programming / Re: Programming habits, standards, and learning.

« on: October 24, 2012, 08:12:21 AM »

Good language choice depends on the paradigms of programming you're most comfortable in.

There's been a lot of discussion of C++, but I don't think anyone's mentioned that a lot of its complexity comes from being a multiparadigm language.  If you've got a good amount of exposure to not just imperative or OO programming but also things like functional programming, generic programming, metaprogramming, highly declarative style, etc.

If you grok this stuff and can spot when to usefully apply it, you can make C++ into a wonderful power tool for the right kind of job.  Of course, if you grok all that stuff, you're probably pretty good at picking up new programming languages generally.

Personally, I value C++ for its expressiveness and ability to create powerfully general solutions.  I find these unmatched in other languages of my experience, with Python running second due to its powerful and friendly functional programming support.  That suits me because I'm inclined to devote my obsession to such generality, but I think that many people just want to make a game and should avoid this route because they won't get enough out of it to justify the learning curve.

In practice, I find that memory management is not one of my more typical stumbling blocks; it used to be more the case before the advent of smart pointers, which reduce the problem to not much more complexity for 95% of cases than that of e.g. Java.

I'm trying to think of what I would consider my most common stumbling blocks.  Honestly, most of the time when I'm sitting there thrashing without making progress it's not really a language issue, but a visibility issue -- I just can't get the proper view on things to make obvious what's going on.  The best tonic I know for that is a strong willingness to take the time and build visualization in when you feel the need and can remotely justify it, because it pays for itself very quickly and keeps on paying.  Plus, you never know when cool new gameplay might come out of it.

Here is a truly excellent talk about immediacy in design that pertains to what I'm saying.

Okay, if I have to pick a C++ stumbling block though, I'll pick linking.  Always a PITA, one way or a damn nother.

To anyone who feels like they wish to use C++ but can't quite get over how screwed up it seems to be, I recommend reading Bjarne Stroustrup's The Design and Evolution of C++.  It's a charmingly personal, incredibly informative, and quite readable account of the language's early history.  Many design decisions are given detailed explanations that shed wonderful new light on C++ and the problems of language design in general.  I promise that reading this book will instill in you great new respect for Stroustrup, and at the very least grudging respect for the accomplishment that C++ represents.  Understanding why things have to be the way they are, what the compiler needs, etc. tends to make programming in C++ a lot easier because it feels less arbitrary (and hence easier to remember, too, since it's rooted in some principle).

4

Programming / Re: "Free-Roam" Roguelike Development

« on: August 14, 2012, 11:41:31 PM »

Another way to go is to arrange for "quests" to arise organically out of the player's other needs, based on game mechanics.  I'm thinking here of Terraria, which has a complex crafting system that sends you all over the world looking for components -- not because an NPC said "fetch me X," but because the player wants X in order to craft Y.  I believe this approach could blend well with what Game Hunter is talking about, since scriptless quests like these are more about world conditions than an explicit storyline.

5

Programming / Re: "Free-Roam" Roguelike Development

« on: August 13, 2012, 10:24:15 PM »

I've had some basic success getting a step beyond "kill X of Y" quests, by creating quests with multiple parts, using stereotypes for the parts rather than the whole.  The idea is that parts can combine in different ways, combinatorically increasing the number of possible quests.

For example, I currently have pieces such as "Rescue Hostage," "Kill Target," "Find Location," "Unite Pieces of Broken Item," and "Learn Fact."  A piece like "Find Location" can be created as a subgoal of a larger goal such as "Rescue Hostage."  Similarly, you can get a basic "Find Item" quest, or you can get several such quests as subgoals of "Unite the Pieces" (one per piece).  My plan is to continue adding content to increase branching factors, resulting in a large number of possible plot "shapes."

6

Programming / Re: Copyright!

« on: July 18, 2012, 08:05:28 AM »

I say only go forward with it if your future happiness does not depend on not getting a cease-and-desist.  Assume you will be noticed, because that's playing it safe, and you're going to invest a lot of time in this thing.  At that point you'll either have to keep it to a very restricted audience, or spend a bunch of time reworking it into some other theme.  You may have a limited audience of close acquaintances in mind now, but once you've built it, wouldn't it be nice to let more people enjoy your work?  Infringing copyright puts that at risk.

Personally, I think you're better off doing a takeoff rather than a direct, branded, copyright-infringing tribute.  Can't copyright a concept.

7

Early Dev / Re: MicRogue - Update Jun 19th

« on: July 17, 2012, 04:04:24 AM »

You could always split them up some.  3 snorknads on difficulty level 4, 7 of them on difficulty level 5, etc.

8

Early Dev / Re: MicRogue - Update Jun 19th

« on: July 12, 2012, 10:34:52 AM »

I like the idea of coins as time.  Reminds me a bit of how arcade racing games give you a certain number of additional seconds every time you hit a checkpoint.  The king should reward you with enough coins to survive the next level, even if you're close to zero; the bonus you get for finishing with extra time/coins is that much extra survivability in the future.  This would put an interesting spin on any opportunities to spend money on equipment, if you wanted to introduce that (don't know what equipment would mean in a 1HP game, but these ideas could apply to other games) -- invest in power so you can survive the enemies, but spend too much and you may lose on time.

Of course, the down side to carrying over your success is that you also carry over your failures, eating up your hard-earned surplus all in one go.  I'd say, though, that's no different from, say, burning through scarce healing potions too early on in BRogue.

9

Other Announcements / Re: Rogue tournament

« on: July 09, 2012, 01:08:33 AM »

Web player Rogue v5 is very slow for me as well (not quite a second, but painful), and my ping is 112ms.

10

Programming / Re: Roguelike graphics project

« on: July 06, 2012, 06:44:18 AM »

100% agree with transparent.  Sprites want to be layered.  Floors may have their own sprites, or items underfoot, etc.

11

Programming / Re: Weapon durability

« on: July 06, 2012, 06:42:14 AM »

I tend to hate durability systems for the same reasons as everybody.  I think it comes down to the fact that when you get a new piece of equipment to put on, it feels like something that's supposed to be yours to keep, and it's a downer when something like that gets permanently damaged (or damaged in a way that's troublesome to fix, like wasting a scarce enchant scroll).

I wonder if it could be made fun, though.  Like, what if you took it really far?  What if weapons and armor degraded so fast that you were really replacing them all the time?  I think they'd start to feel a bit like ammo.  Eventually you'd overcome that feeling of "this is supposed to be permanent," and adapt to doing something more like living off the land, using what you find.  Other styles of games, such as platformers and shooters, do stuff like this all the time, and it's lots of fun.  I think there's a lot of room for roguelikes to explore in that direction, so I'm all for this kind of departure, but only if it fits with your game.

12

Programming / Re: Experience Points

« on: July 06, 2012, 06:32:10 AM »

I'm not using XP either.  My current thrust is an attempt to overcome some of the traditional shortcomings of leveling individual skills through use.  I think this approach deserves more exploration, because I'd like to think it could lead to something that feels more like natural learning than the chunky "all of a sudden you've got a skill/hit harder/whatever" approach of typical XP systems.

Learn-through-use has some traditional shortcomings.  As was mentioned, one problem here is that you tend to get committed to whatever you've practiced, limiting your realistic options as you go forward to those which do not instantly cripple you as penalty for changing your mind.

The second problem I see, in games from Secret of Mana to Dwarf Fortress, is that this kind of system requires pointlessly gamey grinding to advance certain skills, simply because you use them less often (e.g. a "teleport to town" spell vs. the fire bolt spell you use in every fight).  Players shouldn't have to do things like go get wounded on purpose so they can grind healing -- skills should advance naturally when you use them naturally.

I don't know of any games that overcome these two obstacles.  I suspect there may be some very fine gameplay on the other side of this boundary, so I've been working up plans to get past it.

My approach involves a couple of things.  First, skills are rubberbanded so that when you try something new, your skill level is never below some lower bound provided by links to similar skills (or failing that, some underlying attribute like Intelligence).  The Shadowrun tabletop RPG had a system like this, IIRC.  So for example maybe you've got 10 skill with bows and suddenly you find a magic crossbow you'd like to use.  The system may determine that these skills are similar enough that you can use a crossbow with, say, a -2 penalty.  Or perhaps it turns out you're something of a jack-of-all-trades with ranged weapons, but expert in none.  This may give you a high score in the overall category, which could be used at maybe a -3 or -4 penalty (or whatever numbers make sense in the system at large).

To reduce grinding, my system rewards doing new things by associating learning with surmounting challenge.  If you've cast the same spell 100 times, or killed 100 goblins, there's little more to learn from doing the same again.  The skill gained from such practice should enable the player to venture in new directions, to find new challenges to learn from.  Also, the system rewards near-misses (in proportion to nearness), because of course we learn from those too.  I think if you fight a terrible monster, injure it non-fatally, and escape within an inch of your life, you probably learn something in the process!  Shouldn't the game represent that?

Of course, there will be all kinds of balance issues, exploits to consider, and so on.  Still, I'm hopeful for this approach, because XP just seems boring to me.  Then again, maybe it's just personal bias against simple linear approximations for complex processes; see my other thread on doing away with hit points.

13

Programming / Re: Procedurally generating one or more families/a small population?

« on: July 06, 2012, 03:28:59 AM »

I think you should listen to Omnomnom.  If you're tying yourself up in knots and circularities trying to produce working data structures that resemble family trees, I can almost guarantee you're prematurely optimizing.  Use lists, keep it simple, get it working.  You may find that the "slow" approach is blazingly fast.  Tree implementations carry overhead, as well -- asymptotic complexity (big-O) isn't everything.  I'd wager the population sizes necessary to make your concept work are far smaller than anything you'd need to worry about doing O(n) scans on, unless you're doing many of them in a single frame.

If, once you've got it working this way, you discover a performance problem, you can narrow it down and implement targeted optimizations in an appropriate way.  Most likely this would involve adding pointers between list nodes, or some auxiliary index structure that points into the list.

If you do it this way, you're unlikely to get stuck trying to come up with a one-size-fits-all structure that can handle all your current and future needs.  Requerent points out the many different rule structures that can accompany marriage, inheritance, etc. (check out Crusader Kings 2 if you really want to get the flavor of this).  However, I don't think the answer is to try to figure everything out ahead of time -- it's just too easy to wind up changing your mind later.  Instead, recognize that this is a high-variability area and don't link it too closely with lower-variability concepts such as the simple fact of having a population of people.

Why should family relations be the primary indexing structure for them, anyway?  Sure, there are times when that's the important aspect, but aren't there other cases too where it doesn't matter?  If one village wars with another and you need to find troops for the militia, it's more about who can swing a sword than who can marry whom.  Or if you're figuring out who's going to die of old age this year, you care about sorting by age, which again has nothing to do with relatedness.  There are countless examples -- the point is not to couple your core data structure too tightly to a particular use case, because you'll go nuts adapting that specific structure into other specific needs.  Much better to just use a simple structure that can adapt easily as needed.

14

Early Dev / Re: MicRogue - Update Jun 19th

« on: June 27, 2012, 04:21:43 AM »

Those are tatami (rice husk mats), traditional Japanese flooring.  And yes, I believe that's what you'd find in most dojos AFAIK.

Of course, you're doing a fantasy game and it's your own anyway, so do what you think is good.

15

Other Announcements / Re: So I am Buying Diablo III

« on: June 27, 2012, 04:19:27 AM »

I got it on launch too, played intensely for a couple weeks as I tried out several characters and picked one to start hardcore with.  Got a barbarian to level 37 or something and bit it in Act I Nightmare.  Didn't feel like playing anymore after that.  I think I might have been a little relieved.

They've done a great job of polishing up the formula; personally I find it's a formula I've mostly outgrown, though I'm not unable to enjoy it.  I think even those who dislike and disparage the franchise should pay attention to the design refinements if they care about understanding evolution in game design.  The streamlining between D2 and D3 is strongly evident, and shows a good instinct for finding the game in the game and cutting out the rest.