Jump to content

  • Log In with Google      Sign In   
  • Create Account

Blind Radish

Member Since 20 May 2007
Offline Last Active Jan 26 2013 10:34 AM

#5025228 Haskell kicking my Asskell

Posted by on 24 January 2013 - 03:20 PM

So I'm trying to learn Haskell with an extremely simple lfsr program.  I've have working code and I've got a decent understanding thanks to the first half of Learn You a Haskell for Great Good, but I'd like to apply some of what I've learned before I go too much further.  I keep tweaking this code and getting all kinds of cryptic errors, but I think I've got it close.  If anyone can help me understand what's gone wrong, that would be awesome.

This throws an error complaining about "infinite type" occurring in post.  I think it thinks I'm trying to be recursive or something.  Any thoughts?

{- Random Number Generator -}

import Data.Bits
lfsr mask seed
	| (seed .&. 1) == 1 = post
	| otherwise         = post xor mask
	where post = (seed shift (-1))



#5015693 [MMORPG] A new method of presenting the player a new kind of quest.

Posted by on 30 December 2012 - 02:47 AM

Short simple quests to ease grinding.

Over arching quests for anything that doesn't involve leveling up.

Like if you set a level cap every nth level and require the player to complete one of three quest chains to remove it.
Well then you have a cool system.  Let them know about it, what to do and such.  They'll have fun removing it.

Or for some much needed equipment (something you can't grind off).

It's complicated because no one wants to walk half way across the world to gain a level.
And everything gets out dated when you level.

Instead, WoW used quests to guide the player down a path where new quests await.
So it's pretty bland because 1) they have to mass produce them and 2) they are meant to be handled quickly, back to back.

If you want to do something more interesting, you'll have to get them on a path to solve it.
Why don't you toy with the idea of littering some kind of main quests which unlock the next level among simple quests.
Prevent them from missing out on the big quests somehow, and still keep them marching to the destination.
As you progress you can take this away more and more and make them puzzle it out.  Mainly at the endgame.
Then you have meaningful arcs and they can have their path guide them to the solutions.
Or look at RPGs like Golden Sun.  There are a few gates to the "somewhere in the world" quests, but you can still grind away lol.

Or hell, ditch progression and the endgame all together.  Now you are completely free to do whatever you want lol.

#5015688 What I learned from 21 games on permadeath

Posted by on 30 December 2012 - 02:16 AM

On a completely unrelated note to the conversations going on here... really completely totally not related in any way...

Everyone here should try THIS GAME.

#5014810 Island Generation -- Problem with Duplicates

Posted by on 27 December 2012 - 01:24 PM

I'd rebuild it, piece by piece.  That's obviously terrible advice, but its honestly what I would do.

Although I didn't look at your code, you might try this:
You might want to generate a constant perlin noise and a random location, instead of a random perlin noise and a constant location.

Also try adjusting the map maximums to some number which is coprime to the number you're using right now.  Avoid Mersenne numbers.  If that doesn't work, try again with a number coprime to both of those.  You might be generating a specific repeating pattern or something.  Well, no, the map would be offset I suppose.

Not sure.  Simplify and try to generate more basic structures.  Try to make those diverse.  Then add more depth.

Change each number one by one dude.  It's either a specific algorithm or a specific constant that's throwing you off.

#5013914 Procedural Level Generation

Posted by on 24 December 2012 - 05:22 AM

Just FYI, I've merged those two accounts for you.  All of the posts and data associated with the "MyNameIs" account should now belong to your "Blind Radish" account, and the other account no longer exists.



+1 bro.  +1.

O.P., if you have any more questions, feel free to ask.  I dumped A LOT of information on you, so I expect /something/.
Also, I know that looks scary but it's really not that complex.  Make rooms, place them using method, check for errors.  Easy.

#5013861 Procedural Level Generation

Posted by on 23 December 2012 - 11:24 PM

Before I begin please note that "MyNameIs" is... well me.
I accidentally created two accounts trying to link up my account with my google account,
and now I am now locked out of my google account... account.
But don't worry, this is my main account from back when.

Anyways, lets get started.

Procedural Level Generation is an art form of it's own.
Respect it, and you'll attain replay value for your customers.
Disrespect it, and your levels will be totally lame and people will laugh at you behind your back.
Like they do at Diablo.

Anyway, lucky for you, I am a supreme bad ass at this kind of thing and I want to help you out.
Double lucky for you, I like to listen to myself... type? So I wrote like a five page document here.
It took FOREVER.
Seriously though, its a privilege to be in a position to help, sir. biggrin.png

This is actually super easy for me, but apparently can be quite tricky for many people.
If you're having trouble, Just remember that the goal is to (1) find guidelines that, when followed, produce good levels, and (2) teach them to the computer.

Okay, lets keep the square tile system. It's possible to use other methods, but this seems to be the one you (and most people) are more comfortable with. Don't worry at all, its as good of an approach as any.

An important decision you're going to have to make is "should squares be floors AND walls?"
Dungeon crawls tend use tiles as walls, but in 3D this isn't really necessary.
But it does make certain things easier.

You can actually just place walls between each tile, and work with them that way.
A good strategy for this is to keep an array of North and East walls. Or two arrays, whatever.
Don't worry about South and West walls because they're are somewhere else's North and East walls and you'll let wherever know what you plan to do.

And consider throwing out 1 unit hallways. 2 to 6 unit hallways work just as well. Lets the level seem more flexible.
And if you throw them out you can still use 1 or 2 unit walls, so you get wide halls but thin walls. Nice.

The first question we can ask ourselves is "how can we describe the kinds of rooms we want to create?"
In your example the rooms you display can be thought of as simply a rectangle, two rectangle, three rectangle, and a circle.
(Don't worry about placement and collisions yet, we're just thinking about moulding some room concepts first.)

So we begin by generating a rectangle. You probably want this to avoid having either length or width as 1 unit.

I recommend rolling 2(d5) or 2(d6) for this. This will give you a bit of a "Gaussian distribution", making rooms tend to have an average size.
(Remember to add two random numbers, don't double! wink.png)

You can increase the "Gaussiness" of the dungeon by rolling more and more dice, and then getting the average roll and rounding it.
Gaussiness will prevent you from having rooms with a large variation in size.
If you do that, it's better to roll from 0 up, and add a constant minimum after averaging.
And if you want that its better to build it in from the get go, because its a super set of the above method of rolling dice from 1 up and not averaging them.

As you can imagine, room size is very important.
If you want some big rooms and some small rooms, you can add a constant that way to the big rooms, like +2,+2 or +4,+4.
You can also enforce rooms to avoid being square on average by adding something like +2,+0.

Okay, now that we have a rectangle room, how do we make it more interesting?

You have two choices. You can manually build a bunch of interesting rooms, or you can generate them.
I think we're above doing manual labour, lets make the computer generate them! biggrin.png

The above examples add a secondary or tertiary square in a number of manners.
The first room does nothing special. It's important to do nothing sometimes. Its easy to forget that and add all the bells and whistles every time. We'll call this a type 1 room.
The second room is arguably the most interesting. We'll call it type 2 and have to come back to this one.
The third room can be thought of as two squares connected in such a way that they share a face smoothly. We'll call this a type 3 and come back to it as well.
The fourth room is a 1x1. We'll call this type 1A, I want to talk specifically about this one as well.
The fifth room is another type 1 room, but unlike its sibling, it is not perfectly square.
The sixth room is simple two squares connected in such a way that they DO NOT share a face smoothly. We'll call this type 3A.
The seventh room is a cross shape. We'll call this type 4.
The eighth room is a T shape, but we're going to call this a type 4A for now.
The ninth room is a doughnut shaped room, a type 5.
The final room is pretty small - we can call it a type 3 I guess.

Now lets go into detail on the properties we're seeing here.

Type 1 rooms are simply squares or rectangles. As I said earlier, they are special because they are not special. Remember that, it's actually extremely important.

Type 1A is the only room of it's type to boast a width or length of 1. It's more of a closet or micro hallway to transition between rooms.
It's important to the authors of that paper, but it can cause problems for us if we try to carelessly populate it later on.

Type 2 rooms I'll cover in a moment.

Type 3 rooms can be created in two ways.
We can combine two rooms together so that one is aligned with the other's wall.
Alternatively, we can take two rooms, add some constant to the larger of the two, and subtract the smaller room from one of it's corners.
Notice how we can create the same room in more than one way. That's a key thing to remember as well.
The small type 3 should make more sense in this context.

Type 3A can be created in the same two ways.
We can combine two rooms together so that one isn't aligned with the other's wall.
Or we can subtract a room from two corners. In this case it would be prudent to ensure that neither subtraction is larger than half the room.

Types 4 and 4A can be created in more than one way as well.
You can take a square and bevel off it's corners.
You can add a single row that's shorter than a given side along it - either at a constant offset (in this case 1 for each) or a slightly random offset.

Getting back to type 2, we can do a similar approach for this one as well.
We can add to both edges near each wall.
We can subtract a single row from each wall.
We can connect three squares together.

Type 5 is also arguably the most interesting room. It's the only somewhat round room.
An easy way to do this is to take a square and check the distance of every point in that square from some point.
You can use Pythagoras's theorem to get the hypotenuse, then check if the hypotenuse is greater than the size of the circle.
The circle will come out sloppy if the location of it's center isn't at an x,y value in multiples of 1/2 the tiles.

How can we improve upon this last model, the Type 5? We must constantly watch for areas we can improve upon, during planning and during implementation.
1) we could round only one corner at a time. Suddenly, any room might have a rounded corner, and be more interesting for it.
2) We could approximate ellipses instead of limiting ourselves to circles. Ellipses at 45 degrees would be significantly more interesting. And these don't have to be perfect at all. You could merge two parabolas or something cheap like that. Better yet just go with the first method and use variable sized roundness. That will generate approximate-approximate elliptical rooms easily, which is fine because there is nothing significantly more interesting about an ellipse than there is about an approximate-approximate one.

So notice how many ways there are of doing the same things.
If you decide you want to use multiple methods, you must remember that if two methods can create the same room.
If that happens, that type of room is suddenly twice as common as the rest. This can be a problem.

Also, while setting this up, the focus should be on asymmetry vs symmetry.
Specifically look to be one or the other at random or not, and build around that concept.
Notice the symmetrical properties of rooms 2, 6, and 7.
Notice the asymmetrical properties of room 3.
Notice how rooms 6 and 8 seem to display qualities of both, and are more interesting for it.

You might also consider cutting some corners off diagonally, leaving the possibility of triangular rooms and things.
And consider subtracting a room from anywhere inside another room, creating squarish doughnuts as well.
You might subdivide a room in half, or place a room in a room. Make sure these are considered separate rooms afterward, if they are seperate.
Why aren't we worried about generating natural looking caves and the like??
The possibilities are endless lol.

One last warning before we move on - you have to be careful with room modifications like these.
Remember to always prevent properties from existing as 0 or as negative numbers.
Also, be careful not to accidentally allow the computer to cut a room in half.
You have to think about how various combinations might cause you problems, and place upper and lower bounds to prevent them.
Or, you might consider running some tests on each room, like a paint can to check if the room was cut in half, etc.
Better to prevent these outright than to watch for them and patch the problem. Treat the cause, not the symptoms.

This is extremely easy, and there are several ways to do it.

You can choose a random face of the bounding box, and a random place in the bounding box, and walk until you collide with the room.
Bam, door.

You can choose random coordinates in the bounding box and walk in a random direction.
Or walk randomly around.
Or get the closest potential door spot using circles or squares.

Think about making this more interesting though.
How many doors should a room have?
If a door gets stuck in a corner, should we give a small chance to move it away from that corner?
If we make a door, maybe we should sometimes make one opposite it.
If two doors are adjacent, shouldn't we get rid of one of them?

Now that we have all these rooms and doors, what are some ways we can connect them all together?
There are two methods i would recommend for better room placement and connection.
We're going to call these the "Room by Hall" method and the "Room by Room" method.

Placing rooms randomly involves checking for collisions. Fortunately for us, checking for collisions is extremely easy, even with all the fancy rooms.

Each room can be held in a bounding box.
If two bounding boxes overlap, there might be a collision.
You can consider that a collision, or do a more thorough check to see if any tiles in one room are overlapping any tiles in the other room.
(I think you're supposed to use a quad-tree for this, but it's probably fine to brute force it.)

It is important to make sure that if tiles are also being used as walls, the tiles are neither overlapping nor adjacent.
Adjacent tiles means no walls between the rooms.

Upon collision, just reroll the room's location, usually.
But, of course, that can potentially end up in an infinite loop of rerolling impossible to place rooms.
A better strategy is to try to displace the room a little bit, and give up if that fails too much.
Pick a diagonal, like north-east. Move randomly in one of those directions until the room fits or a certain number of moves fail.

You can shortcut that easily by checking outward in a square looking for space that isn't in a bounding box.
Or you can check outward in a circle, or look for space that isn't part of a room.
These might be a bit slower, but this whole thing ought to be extremely fast either way so use your favorite method.

Room by hall involves placing rooms at random or not-so-random locations, and connecting them with hallways.

When you create a room, add it's door to a list of doors.
Once you're done laying out the rooms, it's time to connect all the doors together via hallways.
My favorite method is pathfinding, with a slightly random path.
We actually don't want quality pathfinding. We want to be able to make mistakes.

First, create a 1x1 hallway out of every door.
We create an imaginary square which connects the two of the 1x1 hallways which we've chosen at random.
(Alternatively, we might choose them based on proximity to one another, or any number of ways! Try mixing randomness with proximity!)
We move in a straight line some random number of spaces either vertically or horizontally from one toward the other.
Along this line we create hallway.

Now while we're doing this, we want to watch for collisions between the hallway and a room, or the hallway and another hallway.

If you feel like the collision with a room would be a nice place for a door, go ahead and settle for that.
Just be sure you keep the door you didn't connect with on the list of doors that need connecting.

Likewise, if you collide with a hallway, just keep it.
Consider continuing straight through the hallway sometimes, or every time. Depending on your taste.

Be careful when generating hallways to prevent a hallway from running along side another hallway.
While it's nice to have variable width halls, this only ends up looking bad!
This isn't a problem if you're placing walls between tiles, of course. Just make sure to keep the walls.

Once all of the doors have connected there's really only two steps left.

One is to run a smart pathfinder from one room to every room.
If it can get from any one room to any given room, all of the rooms are connected.
For speed, pick the most central room to start with instead of a corner room!

Finally, if you want an entrance do the create-a-door thing but do it on the whole dungeon.
If you hit hallway, you ought to deal with that so it looks good.
Either make a new hallway leading to the hallway.
Or make an entrance room where you hit the hallway.
Or reroll. Whatever you think is best.

And if you didn't manage to get the whole dungeon connected or if you have doors left over, no worries!
You can just run the disconnected parts as whole-dungeon rooms the same way you build an entrance.
Probably want to aim for internal doors instead of external doors like you need for the actual entrance.
Once you've found a door for each half, connect them.
If you run into any problems, you'll have to retry or plow on through rooms and stuff, there shouldn't be too much in your way.

What is room to room?
Room to room is much like the method used in the example you gave.

You begin by building a single base room.

Next, you build another room, this time with a door in it.
Aim to place the door randomly on the dungeon you've made so far.

If they don't fit there are a number of strategies you can use to quickly get them to fit:
Slide in one direction until a fit it made or you 'fall off' the dungeon's 'surface'.
Mirror the room and try again - it might be blocked by some weird outcrop.
Place a new door on the room you're working with and try that one.
Rotate the new room and place a new door on it to try, ya know with a new wall.
Connect them with the shortest hallway required to make it work.
Connect them with a random length hallway.
Try inserting a new room between the two, maybe one designed to be smaller and more round (round usually fits better).
Anything else you can think of, really.

Finally, build the entrance the same way you would for "room to hall".

So get this - you aren't really required to check for collisions.

Yes, this is as cool as it sounds.

First of all, you've build fancy rooms out of addition and subtraction of less fancy rooms.
Why not just do that again?
Either fuse the rooms - addition, or keep the walls of the new one but override the old room - subtraction. Or do reverse subtraction by finalizing each idea once placed, and filling new ideas around the old but only replacing unused space. In case your not following, this is where you subtract the old room from the new room instead of the other way around.

Using either room to hall or room to room still works all the same, except room to room is arguably more bad ass with this feature enabled.

It would be wise to ensure that rooms which are thought to collide, actually collide or don't.
If you decided you want to allow your rooms to collide and you want non-square rooms, you might be vulnerable to a specific bug - certain parts of the level will be inaccessible.
You might want to do a paint can check and cull anything not connected to the rest of the dungeon.
And/or purge any rooms that are now significantly smaller than they ought to be, or the smaller halves of any cut in half.
And when placing doors, make sure the door placement algorithm and others know all about all the new changes.

Never take something like this for granted.
These are the kind of potentially game breaking bugs that crop up from detailed generation.
They can be easily dealt with, if you pay attention to the choices you make.

Also, this ends up creating a kind of scaling look, so it's a good idea to start with multiple rooms or one central room.

For underground dungeons, sprawling randomly and leaving huge gaps is ideal.
For above ground dungeons, it should be fleshed out fully.

Paint can flood from an imaginary border around the level's bounding box so that all of the outside gets filled.
Flood the dungeon itself.
All that will be left is the empty internals.

Either fill them with rooms in a reverse subtraction fashion (preserving the rest of the dungeon).

Or press the walls of surrounding rooms in randomly to fill them.
This can be done by picking a random adjacent room and walking it's wall into the depths a random number of places.
Repeat until there is no depths left.
You will get funky rooms out of this, but that might be nice.

Trying to give a dungeon a particular 'feel'? Trying to make more interesting layouts?
Conflicted between opting for feature A or B?

The beauty about this line of work is that finding yourself debating two tough choices provides the solution to making better dungeons.

Look at a the options I've provided along the way. There are tons of them.
Think about all the variables, constants, choices, directions, shapes, sizes, probabilities, whatever.
Specifically, how many rooms should you have? How large should they be? What shapes should they be?
How many doors? How direct should you get around? How much hallway? How jagged of hallways?

How will you ever know how to make great dungeons with all those dials to be tweaked?

Well it's simple, really.

Each different dungeon you want to design should have a configuration file.
If you don't have different dungeons, each floor should.
If you don't have different floors, each wing should.
If you have just a single wing on a single floor, each game should have a configuration file.

The configuration file will help guide the dungeon generator to creating a consistent theme.
Even if you only generate a single random dungeon, you should generate a consistent theme randomly.
The theme will push the randomness towards consistent randomness, and make the dungeon feel more realistic, even if that theme is randomly selected.

Things can be given a weight value, and you'll have dungeon flavour before you know it.
For example, one dungeon might tend to have rounded walls, another would avoid them entirely.

One dungeon might avoid hallways.
I'm sure you get the idea.

A cool concept is to change your parameters slightly as you descend deeper into the dungeon.
The rooms might get bigger, for example.

If you are pondering this, you're not paying attention.
It is entirely possible to mix these together freely.

You can build 'wings' in a room to hall style with large, sparsely placed rooms in a large, and then generate smaller rooms room to room style.
This will provide long hallways with lots of side areas to explore.
You can wait to connect everything until the end to make sure the halls won't get you everywhere.

You can limit the number of doors per room to exactly one, and create a very linear dungeon.
You can generate large clusters of room to room style rooms, and connect the clusters with hallways.
You get the idea.

Don't forget, if you're generator supports wings, you can assign themes to each one for bonus points.
Try to stick to an overall theme though.
Or don't! It's your game and I'm sure you'll make it cool!
The point is just do whatever feels right with the theme and such.
If your theme is that wings have different themes, you're being consistent with your theme lol.

A good dungeon generator takes tons of parameters.
A good dungeon picks a small subset of these to adhere to.

Keep your room and door tables around, they might come in handy. And hallway tables if you can.
You ought to be able to build conceptual rooms, like vaults filled with treasure and with only one door, or the boss room deep within.
Traps in hallways, maybe? A big fountain in one room?
Basically later on you can reuse these ideas.

Also, you can generate rooms with room-themes and configure them. Connect a mess hall to a kitchen, that kind of thing.

I don't know but I hope you get the concepts here.

Phew okay I'm 1000% done.
If you show me some progress, I'll consider hooking you up with level 2 of my talents. There's A LOT more to cover.

Also also, I better get a +1 for this.  rolleyes.gif

#5013696 Procedural Level Generation

Posted by on 23 December 2012 - 10:20 AM

Well what kind of a game level are you making?  For that matter, what kind of genre?
You really should design around mechanics.

Now I'll go ahead and assume you want to build levels like you might see in the Legend of Zelda.

You'll want a few great rooms.  The entrance, the level's hub area, and the boss room are good examples.
You'll want these to wow the player.
You can make them grand but mechanically plain, or you can fill them with a fight or a puzzle or some unique challenge or traps, whatever.
It doesn't really matter.  They just have to look cool.  Probably not traps.

Think of the great rooms as floating in abstract space.  They will eventually connect but right now it doesn't matter where they are.

You want to build them to look grand, so think of interesting shapes and such.  You can hand craft these or build them from variable templates.
Maybe ovular, or perfectly round, or extremely tall.  You usually want them tall.  Maybe cross shaped.

Place doors on them.  Build rooms around that.  Rooms can be any shape but try to build from a conceptual theme.  Rooms can be hallways, or whatever.

Figure out how you want to connect all the rooms.  The boss room should be deep, but direct, usually.  You might consider creating an artificial wall of some kind.  A locked door or a cave in.  Unless the dungeon theme says that the throne room should be absolutely hidden.  Just make some dead ends and fill them with loot or whatever.

Unless your doing a multiplayer game, no dead ends for those, usually.

I don't know man, why don't you explain the map you listed, what your goals are, that kind of thing?

I actually have {this one link for you that will show you one example of level generation}.
Notice how he breaks generation down into a series of objectives and tries to create a solution.

{Here's one on natural cave generation}, but look up Perlin noise too, that seems to be popular.

Think about how you would lovingly hand craft a level design.
At each point where you have to make a non obvious decision, pretend you make two levels, one of which makes both decisions.
Teach the computer how to do that and have it randomly make those decisions.
Explain to the computer how you want it to generate levels for your game and it will.
If you do the room based system you can fill them with anything you want.  Generate a skeleton and fill it with more interesting properties.

I'll answer all of your questions to the best of my abilities but I'm not really sure what you're trying to do or how I can explain this better.

{Markov Chains are nice for random stuff, but might just confuse you worse.}
{City Generation}

#5013397 Procedural Level Generation

Posted by on 22 December 2012 - 07:03 AM

You hit the jackpot, sir, this is my demesne.
I was /born/ for this.

Okay, first the prototype.
Manually design the type of level you want to create on paper.  Try to make each room as original and unique as possible.  If you feel like there ought to be a throne room in the back, place one there.  If you feel like one of the rooms should have a high ceiling, mark it on the blue print.
Try to contemplate and then visualize what kinds of things you want to have.  Make two or three potential levels if you want better results.

Now the description.

When you're satisfied with your map concept or concepts, try to describe the room to an imaginary person who is completely non-creative.  While doing this picture in your mind only the things you describe.  Try to avoid taking things for granted, like the fact that this dungeon would have brick walls.  Unless you describe it, it doesn't exist.  Don't find yourself saying "of course there would be a throne in the throne room.  Instead, describe it in great length to the imagined person.

Trial by prodding.
Describe the reasons why you would want these things and why you placed them where you did.  Explain and rationalize your decisions.  Parameterize them.  Create a ruleset for why this type of a dungeon would need brick walls and a throne room.  Try to think of exceptions to those rules.  Try to think of other consequences of these rules.  Of other potential outcomes that might function in place of the original design.  Try to think of other similar rules that might apply.  Placing limitations can help.
The throne may or may not sit above a large staircase, for example, or it might instead be a round table.  Try to break the rules and see what happens.
Really, the point here is to push the limitations and establish a firm description of what needs to be created and what needs to be avoided.
Ultimately, your looking to expand your original model.

The final definition.
Finally, convert your thoughts into a written list of room types, frequency, qualities, and variables.  You can teach the computer to generate these with somewhat random parameters.  The more choices you have, the more potential results you'll get.  Try to make everything a range of choices rather than one definite idea.  Give everything wiggle room.  Also, if you create a dumbed-down version of your model, you can roll some dice or something and draw another concept map.  Is it as nice as your lovingly crafted ones?  If not, why not?
You also might want to run your idea for a design by someone, especially after you have a working generator.

Once defined, its a relatively trivial matter to explain this to a computer.  Just use the lists you created and finagle the results.
Don't limit yourself to squares.  Use hexagons, or even circles.  Why not?  You can just as easily prevent collisions.  And why prevent them, anyway?  Merging can make for more interesting layouts.  Or just wall one off from the other.  Whatever.  You can allocate general room locations, build the rooms, create doors and connect them with other rooms or hallways.  I'll leave the details to you to figure out, because it'll change based on every different idea.  But you've already got the idea that will pretty much work.
And measure everything in smaller parts.  Half square meters, maybe.  And make some hallways wide enough to pull a camera through and fight in.  Claustrophobia can be awesome if used correctly, but shouldn't be used all the time.

Other thoughts.
Your focus should be on layout, function, personality, and depth.

Layout means the arrangement of the rooms should be condusive to a fun experience.  The paths the player can take should be generated to be exciting and interesting, and should give a tour of the dungeon.  It should also make sense in a general sort of way.  Remember to think like the builders.

Function, is very similar to layout and should be pondered at the same time.  It means things should have a logical arrangement.  You should see necessary rooms to add realism to the result.  Kitchens and archer windows, for example.  Also, everything should be in a sensible place for what it is.  In a tower?  Why is it labrynthine inside?  Why is it rigged with traps?  Or does it hold some mystical or spiritual artefact?

Personality is a sign of culture.  Did the builders of the dungeon use it frequently?  Did they use it recently?  Are they using it now?  What belief systems do they have?  What taste in art do they have?

Depth is literally depth.  Keep thinking about how the level in relationship to the player would wow them.  Vaulted ceilings, balconies, bridges over the room below.  Latters, ropes, lookout points, and obviously staircases.  Forget 2D and stay as far away from it as possible.  If you struggle with this one, at least think in terms of top down Zelda/Pokemon layouts.

Well that's it.  Knock yourself out.


#5013148 teach me Primitive Polynomials of Field Theory? Links provided!

Posted by on 21 December 2012 - 09:45 AM

Thank you for trying to help me!


Okay, so I need to understand primitive polynomials, but I haven't got much in the way of math.
Good brain and willing to learn but no school, really.


Please help me understand {this page explaining primitive polynomials}!

Also {this other page of the same}, which seems more basic but is still difficult.

{The easiest one of all}, but again, I don't get it! :'[


The only kind I need to understand is the {kind which is used in LFSRs}, which is called GF(2), right?


I need to be able to generate every primitive polynomial in GF(2) of a given degree.

{This paper discusses what must be the fastest way to test if a polynomial is primitive} - I don't understand what he's saying though.  Probably because I don't understand the definition of a primitive polynomial.



That's all I need to do.  But I also need to understand /why/ it works, or /how/ it works, or anything!

I don't want code, I just want to understand the properties required to make a polynomial "primitive".

The point is that I need to understand it enough to write the code for it.

Sorry if that's confusing.  Simply put, all I need to do is find every primitive polynomial of degree n for GF(2) using one of the algorithms provided, and in order to do that I need to understand what makes a polynomial primitive.

#4941091 Links to Pseudo-random Theory?

Posted by on 17 May 2012 - 08:24 PM

The US National Institute of Standards and Technology (NIST) has a suite of tests that are also popular:


Some brief descriptions of the tests are at:


Yep, that's the one I found earlier. Thanks for the link though, I had misplaced it recently.

..."Approximate Entropy Test". The basic idea is to take your bitstream and break it into m-bit chunks, where m is 1, 2, etc. and see if there is an imbalance in how frequent each chunk is. For instance, take the bitstream 01010101. If you break it into m=1 bit chunks, you'll find that the chunk 0 and the chunk 1 both occur with the same frequency, so there is no imbalance. Awesome. Next, break it into m=2 bit chunks. You'll notice right away that the chunk 01 occurs four times, but not once did the chunk 00, 10, or 11 occur. Not awesome. That's a big imbalance, and obviously the bitstream is nowhere near random. Of course, your bitstream would contain more than just 8 bits, and your m-bit chunks would get larger than just m=2.

Hey wouldn't {0000 through 1111} automatically contain every combination of {00 through 11} exactly twice?
I mean if you didn't overlap the bits.

Essentially, a greater entropy means a greater balance in the frequency of symbols and a greater incompressibility. Get your toes wet with the Σ (summation) symbol by getting to understand how to calculate the entropy of a bunch of symbols: http://en.wikipedia....eory)#Rationale

Here's the equation for Shannon entropy in natural units. Don't think too hard about it until after you read the next few paragraphs:

Thank you for the effort here sir! Gonna need a while to mull this over though, but seriously, thank you.

#4935758 Links to Pseudo-random Theory?

Posted by on 28 April 2012 - 10:59 PM

Thanks so much guys, you all have been so helpful!

I should easily be able to come up with something random in around 80 simple operations.
I was thinking the limit might be 30, so this is awesome news.

Why would you write it as "shift 2, then shift 3" instead of "shift 5"?.

Mainly I was just wondering what it looks like down at that level, ya know for personal growth and everything.
But I was planning on scraping a byte by using an extra shift after a xor. It's complicated lol, but I'd do anything to avoid modulus cycles. Posted Image

1.67) Oh one more question I guess - are if/else branches 1 cycle as well or are those more complex?
My gut tells me they are bad for RNG lol.

#4935756 Links to Pseudo-random Theory?

Posted by on 28 April 2012 - 10:51 PM

Thanks guys, I was just wondering what it looks like down at that level, ya know for personal growth and everything.

I should easily be able to come up with something random in around 80 simple operations.
I was thinking the limit might be 30, so this is actually really good news.

#4928361 Getting Started

Posted by on 04 April 2012 - 08:03 PM

Yep, if you really want to get started right away, XNA and Unity are the way to go I hear, though I think XNA might be easier. Unity confuses me, personally.

That's if you're really bent on 3D.

You could try to learn Objective C and XCode for iPhone projects.
Or Action Script 3 for flash games. Those are rather viral and even marginally profitable.
Or just make 2D games with XNA, which is also a good way to make money.

Personally, I'm going the directX route, which is what XNA is based on, via SlimDX. I don't recommend this route!
Problem is, I want to use the new technology that isn't available on the XBox. Plus, no tutorials in C# for this, which is the language for me.

I also do not recommend using C++ or Java to make games with. You really don't need that much power just yet since you don't have a fleet of artists, and more importantly you need to get going straight away. Use C#. A little slower now because you have to learn it, but "you'll get much faster production once you get it" is what I keep hearing over and over.

Also check out Blender for modelling 3D stuff. It's not my favorite but it's an alternative and you could check it out.

#4926230 Efficient data structure for a maze

Posted by on 29 March 2012 - 12:18 AM

Um I don't know why anyone hasn't mentioned to use one 2d array of tilegraphics, one 2d array of N-S walls, and one 2d array of E-W walls.
The walls should be one more or one less than the tiles, depending on if you want to store the outermost walls in the arrays or just assume they are there in the code.


Then do something like check n for South or East and n-1 for North or West in the relevant array (assuming 0,0 is in the upper-left quadrant).

You probably don't need tilegraphics, you could just assume that if a tile is surrounded by walls on all sides make it black, otherwise make it white. Then draw the walls in.

Like the other guy said though, most people just do one array of walls and tiles, where the walls are a type of tile that you can't access ever, from any side. Not like PacMan but more like Rogue. Although I think PacMan just uses 16x16 tiles and says that an empty tile is the background color and usually sticks two of them together at once to make a pathway big enough for PacMan's fatness to squeeze through. Maybe he shouldn't eat so much.

If you want to really compress things, maybe for tons of levels, just assume either wall or path and draw lines of the other kind connecting everything. Should end up a bit more compact. You could also add a boolean to split the level into two mirrored arrangements. Many PacMan levels are mirrored. You'll need an empty array to store the current level data, but you can store the rest as algorithms or parameters.

#4892876 Help me understand this "getting started" tutorial?

Posted by on 11 December 2011 - 02:19 PM

If you don't know how to program, even the most basic graphics tutorials will be beyond your grasp. Start slow, learn C# basics. Learn to build and debug programs. Learn to use your development environment.

Great, thanks for the nay say and the -1. So can anyone help me out or is this just a Troll site?
This is a legitimate question.

To state this simply, "Unload Project" is not even on the menu that everyone says its supposed to be on. I mean I looked everywhere I could think of and googled the heckler out of it and it's just plain not where everyone is saying it should be. I can't unload my project because right clicking the project doesn't give me that option and it's not in the project menu at the top!


According to google image search it's supposed to be between "rename" and "open folder in windows explorer". It's not!
Terrorists clearly did it.

I tried not using a Windows Forms Application, thinking that might be the problem, but the option still isn't there!

Is there no other way to do this? Why wouldn't it be there for me? It's JUST NOT THERE.

Posted Image

Posted Image

I think I'm gonna cry, I'm so excited to program and unabled!