Messages

1

Programming / Re: Generating a list of unique random numbers

« on: April 14, 2014, 03:44:50 PM »

Because you could end up with something like 0.000000001, 0.000000002, 0.000000003, 0.000000004, 0.000000005. All unique numbers but all very close. It's pretty much impossible to call random a few times and get duplicate numbers. You have to be careful when comparing or doing math with floats.

Sure, the numbers may be very close, but they are still unique.  Why would their closeness be a concern?  Perhaps in reality the goal is not a list of unique floats but a list of unique integers within a range, say 0 - 5000.  In this case we would of course need to convert the random value to an integer first.  But is that all that was being said?  It sounded more like "a float between 0 and 1 should never be used as a key in a set or dictionary."

As a side-note, I do think it should be possible to get duplicate values.  If we think of an integer as 32 bits, a random positive integer should have its sign bit set to 0, and the remaining 31 bits should be randomized.  Conversely, a random float between 0 and 1 should have its sign bit set to 0, as well as its exponent's sign bit set to 1, and the remaining 30 bits randomized.  This means that a random float should be more likely to contain a duplicate than a random integer (having 2^30 possible values instead of 2^31).  It's true that one must be careful comparing floats when crossing architectures or after performing math.  However, two floats with the same bits will compare as equal.

2

Programming / Re: Generating a list of unique random numbers

« on: April 14, 2014, 03:18:12 AM »

random() is the name of the standard library function which returns a float between 0.0-1.0.  There would of course be no point in putting that as the key in a dictionary or set.

Why do you say that?  Do I not know something about the interaction between floats and sets?

3

Programming / Re: Generating a list of unique random numbers

« on: April 13, 2014, 03:59:32 PM »

However, the line "val in value_list" requires the code to compare "val" to every single value in the list.  As the list grows in size, this could take a longer time.  For this reason, it is better to use a Set instead of a List.  A Set uses hashing so that the same operation can be completed much more quickly:

Code: [Select]

used_values = set()

for x in range(0, 100):
    val = random()

    while val in used_values:
        val = random()

    used_values.add(val)

    // Do something with val, maybe append to a result list or call a function to build part of your map


Note that for every number generated, val is looked up in used_values twice.  Once to check if it is in there already, and once when it gets added (because that's how sets work).  If you take this into account, you can reduce this example to what I wrote earlier.  Of course, you are not talking about Python's random.random() here, that would be bad.

A good point.  It did not occur to me to me to use the length of the set to determine whether or not a value was added uniquely, and I do think that avoiding a second hash is worthwhile.  As for which version of random() I am referring to, I don't know Python, so I can't say.  If there is a certain version of random() that should be avoided, then hopefully someone can explain that here.

4

Programming / Re: Generating a list of unique random numbers

« on: April 12, 2014, 04:30:53 PM »

Even though there is a built-in function, we might still want to understand how this can be implemented.  Learning this algorithm will help us apply apply a similar technique to solve other problems.

I unfortunately don't know Python, but I will attempt to write Python code here using a reference, so forgive the almost-certainly-incorrect syntax.  To write your algorithm as you described it in the original post, it might look like this:

Code: [Select]

value_list = list()

for x in range(0, 100):
    val = random()
   
    while val in value_list:
        val = random()

    value_list.append(val)

However, the line "val in value_list" requires the code to compare "val" to every single value in the list.  As the list grows in size, this could take a longer time.  For this reason, it is better to use a Set instead of a List.  A Set uses hashing so that the same operation can be completed much more quickly:

Code: [Select]

used_values = set()

for x in range(0, 100):
    val = random()

    while val in used_values:
        val = random()

    used_values.add(val)

    // Do something with val, maybe append to a result list or call a function to build part of your map

In the code from your original post, you started with a known list of possible values (random_source_list).  If you have such a list, you could write an algorithm that randomly picks a value from that list, then swaps the value at the end into the spot you picked.  Then the next time you pick a number, you consider the list one position shorter.  This would be fast, but will modify the source list, meaning you might have to copy it if you need it somewhere else.  That might look like this:

Code: [Select]

len = len(source_list)

for x in range(0, 100):
    val_index = _int(random() * len)
    val = source_list[val_index];
    source_list[val_index] = source_list[len - 1]
    len--

    // Do something with val, maybe append to a result list or call a function to build part of your map

As requerent wrote, it makes the most sense to use the built-in version random.sample method to solve this problem, but hopefully these examples were useful in some way.

5

Design / Re: How long do you think before taking turns in a roguelike?

« on: April 09, 2014, 03:01:14 PM »

I think I play similarly to mushroom patch except that I'm typically less patient than I should be.

But just because I usually take my turns quickly doesn't mean that I wouldn't be happy to spend more time on my turns in a game that requires it.

6

Design / Re: Permanent consequences for failure that aren't death

« on: April 09, 2014, 01:51:37 PM »

If the point of permadeath is getting players to go through new randomly-generated levels each time, what about restarting the "level" when you die, but it's randomly generated again, so you're not playing the exact same level. That also prevents the player from just endlessly trying the same situation until they luck into a solution, or scoping out the level before they die to know where the tough monsters are or the good loot is.
That seems like it could work as an "easy" mode that still lets some of the strengths of the roguelike shine through without being too frustrating, or without making it too easy.

Sure, this would be a more roguelike version of checkpoints.  However, there would be less repetition of the levels compared to permadeath, meaning less chance to experience the game's random content.  Compared to a standard roguelike, maybe this solution would make sense for a game that has less to learn from repeated playthroughs, and either doesn't have as much random content or is long enough that the breadth of the content can be experienced through completing the game once.  There are many roguelikes that would be made extremely easy by allowing for restarting at the beginning of a level.  But instead of thinking of this as an "easy mode," I would try to make completing a level difficult so that the game presents a reasonable challenge (assuming you're creating a game where overcoming challenges is important to the fun).  It may also be important to verify that a level is never randomly super easy compared to the norm.

7

Design / Re: Permanent consequences for failure that aren't death

« on: April 09, 2014, 01:34:06 PM »

Randomness doesn't really justify wasting of time. I already invested five hours building my character, I want to see how far it can go.  A roguelike should aim to be enjoyable role playing game, not torturing simulator of tedium and repetition.

I don't believe that roguelikes should be lumped into the category of role playing games.  There is something great about random content generation a regular RPG cannot provide.  Where an RPG unfolds a pre-defined story to the player, a roguelike puts the player into a world where anything can happen.  Though permadeath can cause tedious re-playing of the same levels, it doesn't always.  The goal of a roguelike is to create enough variation that replaying parts doesn't feel tedious at all, that maybe the player is even thinking about the next run before the current one is complete.  But it is the job of designers to figure out where their game falls and to ask themselves which mechanics make sense for their game.

8

Design / Re: Permanent consequences for failure that aren't death

« on: April 09, 2014, 06:26:22 AM »

Fun is subjective, but if your goal is to make challenging game then you can't let your player save at will.  Checkpoints work, permadeath works better, but both are inherently punishing to some degree.

Fun may be a bit subjective, but there are certain things that most people find fun, and things that most don't.  Accomplishing a challenge can be fun, but so too can immersing oneself in a game's story, or building a character to see how well it performs, or exploring a world, or setting things in motion to see what happens.

And a challenging task isn't always fun.  It depends on the specifics.  This is what LazyCat is trying to say, but bowling is a bad example because you could spend your entire life bowling without truly mastering it.  The same can't be said of most turn-based tactical roguelikes.  If I play a permadeath roguelike many times, I actually might figure out all I need to know about early game tactics.  Even knowing the tactics, when I replay the game again I could still get careless and die.  You could say that makes the game more challenging.  But that challenge is just tedious.  It's not fun.  The fun part is learning the tactics of each individual fight, and implementing permadeath doesn't add to that part of the challenge.

Permadeath has its benefits.  It can allow the player to experience the wide array of randomly-generated content that a roguelike provides.  It can also create a sense of importance surrounding each move the player makes, and it can turn what would have been an easy game into an accomplishment to complete.  But sometimes, especially for games without random content, the tedium that comes with permadeath isn't worth those benefits.  In a game where you solve puzzles, it probably makes sense to allow saving at any point.  In a game with static content, well-placed checkpoints often make sense, and in a game with randomly-generated content, perma-death often makes sense.  But these are only guidelines, not necessarily the only way to create your game.  This thread is a good exercise to see if we can come up with new ideas that work in randomly-generated games.

9

Design / Re: Permanent consequences for failure that aren't death

« on: April 09, 2014, 05:20:14 AM »

The permadeath thread got me thinking about other ways to provide meaningful consequences for death besides simply ending the game.

One of the game ideas I have (who knows if I'll ever end up making it) is a roguelike where your only method of character improvement (aside from equipment upgrades) is mutation. Mutations to make you stronger, let you shoot lasers out your eyes, grow extra arms to hold extra weapons, etc.
When you die, you would come back to life at a nearby cloning facility, but the technology is imperfect, so when you come back you'd end up with a bad mutation. The bad mutations could possibly be cured, or maybe the game could eventually end if your bad mutations just get so out of hand you're nothing but a blob or something, but I think it'd be more interesting than just simple "You die, game over."

I've seen some games where when you die, you go to some kind of underworld and have to get back out, either by fighting your way out, or solving puzzles, or whatever.

What are some other possibilites? And are there any games (roguelike or not) that do things like that?

I don't believe that a player needs to fear deep consequences of failure in order to enjoy playing a game.  While some players may thrive on that fear, quite a few successful games incorporate saving and checkpoints.  With saving, players can be presented with a series of very difficult challenges and feel accomplished at each stage of progress.  I would question claims that none of those games are fun.

But for a roguelike, if you remove death then your game is changed so that the player doesn't need to replay any of it.  For a roguelike, this is a problem.  Instead of hand-crafting and perfecting a single playthrough of the game, a roguelike attempts to make multiple plays of the same content interesting using randomly-generated content.  If players complete the game without replaying any of it and have no incentive to replay it, then why even make a roguelike? Why not just build each level by hand?  Any alternative to permanent death should address this, and should also focus on making failure feel less punishing to the player (which I'm guessing is the reason you're considering alternatives in the first place).

I don't have a flawless answer, but here's two random ideas.  Maybe something here will get ideas flowing for you:

1) The simplest way to avoid death is to not create a game where you can die.  If player death is not a feature of the game, then every action in the game can be permanent, and the player can continue to play until the game is finished.  Vanguard suggested something along these lines when he said, "your character survives but the town he was supposed to defend gets destroyed."  That comment might mean that the game plays like any other roguelike, except when you "die" you get a red mark on your final grade.  Or it could describe a gameplay mechanic in which controlling or preserving towns progresses the player toward success in some way.

This concept is similar to restarting a level when you die.  You don't lose all your progress, but you fail to progress toward victory.  The difference is only in permanence.  The town the player was meant to defend is now burning embers on the map, or maybe it's an enemy-controlled fort.  In this example, the player might then be forced to find a new town to serve his purpose, encouraging exploration of more randomly-generated content without requiring a restart from the very beginning of the game.

2) There is a children's game called Telephone.  In this game the first player whispers a phrase into the ear of the second, who whispers the phrase into the ear of the third, and so on.  The last player hears the whisper and announces the phrase.  Invariably people will mishear the phrase and whisper something wrong to the next person, and by the end, the phrase is completely different.  What makes this game interesting is that failure creates fun.  If everyone always succeeded, and the last player always repeated the phrase exactly as it started, then the game would be terrible.  Instead of punishing those who fail, the game's enjoyment comes from seeing how the players' actions caused the outcome.

This principle might lead us down countless paths of roguelike design.  How can player failures create fun in the game?  Many existing roguelikes allow the death of a player to affect the player's next playthrough.  But what more can we do?  What if failing resulted in your character's items being randomly switched around?  Or what if failing altered the player's path through the world itself?  We might imagine a game whose path to victory appears straightforward, but upon failure that path is closed, and the player is redirected through corridors that they never knew existed.

I've occasionally thought about a game which uses some of these ideas.  In this game, the player would control a diety-like character who moves throughout a randomly-generated world, attempting to accomplish a randomly-generated goal.  The player would have no fear of death, but their actions would affect the various NPCs throughout the world.  When the player's goal is finally accomplished or failed, the final state of the various NPCs could be inspected to see how your actions have affected the populace.  I don't know whether this vague idea could become a fun game, but I will like give it a shot at some point.

Anyhow, maybe I've been rambling about nonsense, but maybe something I wrote here will give you an idea.

10

Design / Re: Difficult vs Punishing Games

« on: April 09, 2014, 03:53:17 AM »

It's the player's job to refine their tactics with each playthrough.

Certainly.  Just as the player must refine their tactics, the game designer must assure that refinement of tactics is necessary for the player to succeed.

11

Design / Re: Difficult vs Punishing Games

« on: April 08, 2014, 09:53:01 PM »

I agree that this is something that would make permadeath punishing, but that isn't a concern with most roguelikes. This is pretty much a solved problem.

I disagree with this, sort of.  While I do think that the randomly-generated content of roguelikes goes well with the punishing nature of permadeath, there is more to it than that.  The designer of a roguelike should really think about what the player will find interesting with each new playthrough.  If the map is random, but the player ends up using the same tactics to fight the same monsters and gain the same rewards, then the game will still feel punishing when you die.  It is the job of the designer to craft these new experiences, and to truly be called a new roguelike, each new game should answer this question a bit differently.  So I guess I don't think it's a solved problem so much as a challenge for anyone creating a new roguelike.

You mentioned earlier that dying is part of the game, and that's an excellent point.  But the game designer needs to work to achieve that feel.  I've played some roguelikes where I've been devastated to have to replay the beginning parts, and I've played others where I'm anticipating my next run before the first one is even complete.  That speaks, I think, to how effectively those games integrate death into the game and how well they deal with this feeling of punishment.

12

Design / Re: AutoTileGen - automatic tileset generator

« on: April 08, 2014, 03:36:33 PM »

Both of those products look rather interesting.  I think I'll give them a shot.  If I do, I'll post about them here.

13

Design / Re: My two cents about Permadeath

« on: April 07, 2014, 08:26:25 PM »

Any type of game can have only one life.

I think this is a good point.  I could describe a roguelike using many characteristics of the original rogue: Top-down, tile-based, permadeath, ascii art, dungeon crawler, monsters, loot, etc.  But a genre doesn't need to be that specific.  How many such characteristics can we ascribe to "first person shooter" or "platformer"?  To me, a genre is defined by the core feature that both brings it success and differentiates it from the crowd.  I feel that for roguelikes, this feature is procedurally generated content for the purpose of replaying the same parts of the game many times.  I believe that's the part that lifted Rogue above the rest and is the reason the game is still relevant.

But permadeath works extremely well with procedurally-generated content.  In a non-roguelike, the player's experiences are static, and nothing is lost if the player only plays through each part once.  In a roguelike, a lot of work is put into making each play unique, and the game's enjoyment relies on that.  If we create procedurally-generated content, then a player uses saves so that they can complete the game in one run, then what was the point of the procedural content?  We would have been better off crafting each level by hand to perfect that one playthrough.  It makes sense for roguelikes to have some mechanism that keeps players coming back to the same levels that they've already played so that they can experience the variety of content.  Permadeath isn't the only way to accomplish this, but it is certainly an effective one.

While I think procedural content is the core of roguelikes, that doesn't mean we shouldn't include other standard roguelike characteristics when discussing the genre, including permadeath, but I think they have some flex.  Changes to these other attributes should not necessarily disqualify a game from being a roguelike.  Can there be a roguelike without a tile map?  That isn't turn-based?  Without permadeath?  I think so.  While a genre might specify certain tried-and-true parameters, it should also provide room for games which, inspired by the core of the genre, try something new.  Because of this, I call a game like Spelunky a roguelike, while if I encountered a game that is very similar to Rogue but which has static content instead of procedural, I would have a difficult time calling that roguelike.

14

Design / Re: My two cents about Permadeath

« on: April 04, 2014, 12:38:57 AM »

I don't think permadeath is appropriate for every game.  To me, it depends on the variety provided in each playthrough.  If starting over means that you are faced with no new choices, no new powers, no new monsters, no new levels, etc, then permadeath probably isn't a good choice for that game.  Redoing everything that you've already done simply isn't fun.

That's why randomness is such a key part of roguelikes.  While the player may be a bit frustrated at dying, there should also be excitement to see what the next run will have in store.  And while randomness necessitates some degree of luck, luck can also contribute to this feeling, this idea that anything can happen, that the same game can surprise you each time you play.

While some may enjoy permadeath for just the added thrill factor from the risk it provides, I don't personally feel that is enough.  I've never understood permadeath in MMO's, where you must spend hours grinding to get back to where you were, nor even in games like Diablo, which has random dungeons, but static gameplay and choices.

So it is usually my goal to make repeated playthroughs as interesting as possible.  For me, that's the draw of a roguelike, this sort of unspoken promise that each time I play will be a brand new experience.

15

Programming / Re: Multiplayer roguelike implentation through MySQL???

« on: April 03, 2014, 08:41:49 PM »

First off, yes, it is possible to create a multiplayer roguelike using a MySQL database.  While the others here said that using this database as your server is a bad idea, I will only say that it is PROBABLY a bad idea.  It depends on what you're trying to accomplish, exactly.

I wouldn't use a MySQL database as a server for a game that I am planning on distributing for public consumption.  As the others said, the performance of the database will not be good.  If many people began playing the game at the same time, it is unlikely that your database would be able to perform.  Think about this: when one player makes a move, the other players need to be notified somehow.  The only way they can be notified is by reading from the database.  So they will each have to continually run select statements on the database, looking to see if any other player has inserted his move.  Lots of players all running select continuous selects will bog down the database.

If you want to use the database as your server, your game should meet the following criteria.  First, you should be trying to create a sample game to play between you and your friends, where you expect a handful of people to be playing at one time.  Second, the game should not require anything near real-time updates between players.  For example, if players can only act on their own turn, then it may not matter if players have to wait a few seconds in order to detect that a player has finished his turn.

If your game meets these criteria, then you may want to give it a shot.  Using a MySQL database as your server is the flat-out wrong tool for the job.  However, it is a tool that you know.  In programming, it is common to run into technology barriers: you want to create something, but you have tons of learning to do in order to do it the right way.  This can be discouraging.  In my opinion, while using the wrong tool is less than ideal, it is better than not programming anything at all.

If you want to try a server, then you'll need to understand where and how your server will exist.  Does it run on a computer you own?  Do you have some webspace you can run it on?  What technologies are supported there?  Perhaps your server can run in the same place as your MySQL database.

I also think that creating a server is not as hard as it sounds.  If you provide details about where you might be able to run the server and how your game will work (does everyone connect to the same server and play in the same world, like an MMO, or are there multiple game worlds running at a time?  Do players all take turns, or is the world moving in real-time?), then maybe I can help you walk through the process of picking technologies and getting a basic server setup.