First time poster! Here's a screenshot of the game I'm making. It's about a barbarian wielding a sword and a lasergun... In a post-apocalyptic world!

There better be damsels in laser-bikinis!

I'm hooked at this screen.  You should start a dev log!

My predictions are aimed at Sony and Microsoft, since Nintendo is strange.  Even if I say "all consoles", Nintendo is excluded.

"They'll just have better graphics" croons the peanut gallery, noses turned aloft.

Well...usually it's some form of computational power that drives graphics, which can also be used for interesting things other than graphics.  Those past boosts in power have been responsible for significant changes in gameplay as well, not just graphics.

I predict next-gen consoles are going to have high memory bandwidth input devices.  Right now, the Kinect is limited due to the poor memory bandwidth available to the cameras.  If they can use a faster input, they can bump the resolution of the Kinect's cameras up, and have a far more accurate device.  Plus, better performance and more memory will allow for better image recognition algorithms, which will further enhance what can be done with it.

I do not see the "alternative input device" trend reversing itself, but I do hope it will become more refined.  I think the idea has merit, but the present devices are too crude to be very compelling.  I certainly don't think we'll see the death of the traditional controller until we get direct brain-links or some nonsense.  Still no mouse and keyboard support.  Microsoft might try to integrate Windows Phone 8 (are they even calling it that?) or the Windows 8 family with the XBox 720.

Further, I don't see the trend of "console as home-media super device" reversing itself.

I don't think optical drives will be lost this console generation, but I think this will be their last.  Mandatory installs onto harddisks will likely be more prevalent, unless the read/write time of the next-gen optical drive will be substantially increased, to take advantage of what is likely to be a pretty significant jump in available memory.  I do think all consoles will have high-capacity harddrives, and that we may see most if not all games deliverable as downloads at some point in the next gen to coexist with brick'n'mortar stores.  If they're smart, XBL and PSN will become more Steam-like, and may relax their rigorous nature for the indie market.  The last is a VERY big if, though.

Memory capacity will go up, but more importantly, memory bandwidth will as well.  Given how cheap memory is getting, I think the jump in capacity will be rather significant, which is great given how far consoles lag behind PC's in terms of available RAM.

The next generation of cards driving them will probably be capable of something comparable to DX11, but I think they'll only use single-card solutions rather than SLI/Crossfire setups.

I don't see any radical hardware departures like the current generation (cough cough Cell processor), and that the next generation will be ever-more PC-like than the last.  The PS4 might retain a Cell for legacy purposes, but I'm not convinced Sony would be willing to eat the cost.  I'm not sure if they'll stick with PPC cores or go with something else.

As for some darker predictions, I think EA's idea of used game access codes or whatever they are will not only stick, but become more prevalent on the next gen.  I think consumers will be willing to put up with it, begrudgingly.  The whole idea of digital ownership seems to be mutually exclusive with a digital second-hand market, but perhaps something could come about if the public raised a tremendous stink.  I don't think that has any chance of happening for years, because I think right now it's a new enough thing that there are alternatives, and people by and large don't care.  I also don't think it's destined to happen, but it could start simmering next generation if publishers start becoming highly abusive toward consumers.

I'd give a little ebb and flow about it, maybe conclude each level with an embarassingly easy part that's still capable of killing a player due to tension for that "YASD" effect it gives. So something along the lines of:

end-1-2-3-4-3-4-5-2-end

It (and the second "3") subvert the pacing of directly incremental difficulty, and are aimed at fooling the player into thinking it's an easy section, just because it's easier than the preceding sections. Player carelessness (and baiting thereof) is something you certainly must factor into it. It also allows the sections 1 and 5 to remain distinctly uncommon, thus drawing player's attention towards the 2/3/4 sections.

Yup, that's a good idea.  The beauty of generating off of a difficulty curve is that you can just change the curve and BAM!  Different difficulty progression.

My very starting base is a straight exponential curve, but I've been planning on trying some others around.  I do like the idea of having the hard part be more in the middle, or the ending being slightly harder than the hardest segment.  I can just pick the type of curve I want for the level and generate based on that using the same level gen algorithm.

And personally, I think you'll get better gameplay out of combining sets of two things in creative ways - maybe even do two level-1 segments to simply illustrate how the elements work alone, before arranging them in dastardly combinations together.

You could also plan uber-precise shortcutting intentionally, and put the collectibles as rewards for executing them properly; but I'd place speed scoring as more vital than that; so that if a player whiffs one, they aren't necessarily always motivated to pursue it... in which case they practice it less, and it remains a challenging target for longer.

We'll see.  I'm thinking about that sort of stuff, but honestly combining mechanics versus not combining mechanics is going to depend a lot on how those mechanics work in the first place.  I do already have provisions for generating sets of level obstacles, so it would be as simple as making new sets that are mixed.  Presently they're homogeneous, so you can get 3 laser turrets in a row or something, or 2 pistons, but not a laser turret and a piston.

And...actually those are the only two level obstacles in the game that are statically placed.  There's a third that can fly at you from off-screen, but they can spawn at any time.  So yeah, spawning groups is not off the table, but I'm not yet ready to make a decision on that.

The interaction of collectable patterns and level obstacles, however, is harder for me to figure out.  I'm kind of content to leave their generation decoupled (they're generated off the same difficulty curve, but the patterns selected for one doesn't influence the other).  I'm not precisely sure if there is a strong coupling between the two types or not (that collectable pattern A + obstacle pattern A is 3x harder than collectable pattern B + obstacle pattern A, assuming that the difficulty of Ca + Oa = Cb + Oa without any special modifiers).  It would also be a lot more work for my level generator to have to deal with that sort of stuff, so I'm not going to deal with it unless it ends up really detracting from the game.

Now, if I were making a platformer, yes it would matter immensely.  I'm not though, and the constraints of your game heavily drive what levels you can generate.

Looks cool!  Speaks to me of Gauntlet + Roguelike, which is pretty rad.

^ I would say to plan not how difficult each element is individually, but how complexity factors into the mix with different element combos. Spike ceilings and springboards would both rate relatively low on such a scale, but if you put the two together... 9.9

To me, a lot of it is in layering the elements and generation together. There's many factors you can generate, that can change a lot of things:

The level/map. The gameplay elements thereof. The player/role. The game's objective (speed? completion? kills? score?). Powerups and effects. Heck, if you're really sold on the idea, you can change the game on a whim between hop'n'bop, dash'n'slash, and run'n'gun. That changes a lot of factors, including how to approach enemies.

I agree that when you have elements that interact in a complex or special way, it's a good idea to form groups and balance their difficulty as a unit rather than their individual parts.  I'm pretty sure Spelunky does this, because if you play it several times you notice repeating patterns of trap combinations and platform shapes.

To expand upon that, I think of my game as existing of "execution challenges", and that the play experience consists of the player being introduced to an execution challenge, devising a plan to overcome it, then attempting to overcome it.  An execution challenge doesn't have to be a single element, but can be a group.

Think of Super Meat Boy, for instance (which definitely wasn't procedurally generated).  Many levels are a series of execution challenges with little breaks in between.  You'll have a set of hazards in the level, and a platform at the end of it that's safe.  It could consist of three moving sawblades on a wall that you have to wall-jump through, then a platform at the top that's safe.  There are 6 independent elements at work here (2 walls, 3 sawblades, one platform), but they combine together into a single challenge.  You can't stop between sawblades 2 and 3 and wait to catch your breath, you'll die.  Your immediate goal as the player is to get past those sawblades and get to the next platform, the rest of the level is totally inconsequential.  After you clear the immediate execution challenge, the player repeats the process with the next one, and so on, until the level's complete.

In my specific game, the execution challenges are mostly atomic, meaning they're not composed of sub-parts (for now, this is subject to change as I gather testing feedback).  For the most part, there's one enemy per section of the level, and you encounter groups of collectables in serial.  The challenge stems from playing with perfect execution.  The most important thing is that I am actually working with execution challenges that have a group size of 1, while many games (Spelunky and most platformers) work with an execution challenge group size > 1.  I should have been more clear, but the real point I was trying to make is that you can string together mathematically represented execution challenges to do procedural levels.

Oh, and yeah. I try to avoid going outside when the temperature is -10c. I assume the author lives in the southern hemisphere.

California, near San Francisco. It is supposed to be the rainy season now but instead we keep getting sunny and 20c.

The weather in San Francisco has been disappointingly cheerful.  I really want it to rain.

I like to work outside, but I don't like getting much sun.  Working in parks is cool since they often have a lot of shade.  It's something I reserve for weekends when I have some free-time since it requires me hauling myself and a laptop to a park to begin with, then hauling myself and said laptop back when its battery dies.

I don't think it makes me more efficient, but it's fun to stare at something other than my wall sometimes.  It's worth it to keep me from going crazy.

Edit:  I like Golden Gate park for working in, in case you're looking for a specific place in SF.

Well, I think people react to glitches in different ways.  It's something of a joke to gamers how buggy Bethesda games are, to the point where people accept extremely buggy games from them that would get panned if it were another studio.  However, I've also seen people that did not appreciate the weird and whacky bugs of Skyrim.

Some people like playing Goldeneye with big head mode and paintball mode on, and I'm sure they'd love the intrusion of a spinning jockey.  However, some people are looking for a more serious experience, and it might be quite intrusive/upsetting to see someone start spinning wildly while riding a horse.

As to whether or not you should keep these glitches in...well...they ARE glitches, so you'd have to QA them pretty hard to make sure your hilarious horse spinning bug isn't actually a not-so-hilarious horse spinning and save game data corrupting bug.  Perhaps if you think your target audience would appreciate the humor of that, then sure, keep it in (but maybe make it less of a glitch and more of a feature, just to be safe.  The programmer in me is really nervous about people wanting to keep glitches in software).

I honestly thought this thread was going to take a different direction.  I think my real answer is this:

Does this glitch further the design goals of your game?  If so, consider making it a feature and leaving it in (after taking steps to make sure the glitch won't destabilize your game).  Really, the only difference between "glitch" and "feature" is intent.

Glitches frequently become part of gameplay in competitive games, and if they significant to the gameplay, they can get rolled into the game design officially.  I don't know the design history of these games, so I'm not sure if they're actually glitches (I think they might be) or were designed this way from the get go.  Fuzzy guarding in fighting games is a technique that, while not REALLY a glitch, is players using the block system in away that I don't think was originally intended.  It's good for competitive play, though, so it has stayed around in many fighting games.  Denial in DotA is also something that I'm not sure started off as a glitch (or as an unintended consequence of DotA being a WC3 map), or if it was intentionally designed into the game.  Regardless, it has become very core to the gameplay.

I do not think it's any excuse to be lazy in QA.  For every adorable glitch, or every glitch that actually helps gameplay, there are tons that make the game worse.  I would never advocate letting up on QA to try and generate those feel good spinning horse moments.

I've been grappling with procedural level generation for a game I'm currently working on. My answer to this is to use a lot of math.

The game's something of a runner game (Canabalt, Jetpack Joyride and those sorts), so I need to generate levels that are challenging for the player and follow a good progression of difficulty. 

What I've done is examined the elements that make up my game and attempt to describe mathematically how "difficult" each element is.  There are collectable widgets that you can get to increase your score, but you're trying to get through the level as quickly as possible, so the "difficulty" inherent in a pattern of collectables is how many times you need to traverse the area of that pattern to completely collect it.  If I know the size of a pattern, then I can figure out that pattern's "effective distance", which is how many meters you need to travel to completely collect the pattern.

Hazards in the level likewise require you to dodge, and will have an "effective distance" needed to dodge past them safely.  However, there are other things that make patterns more difficult, such as ones that sort of surprise the player and demand them to reflexively dodge versus ones that require precision movement but aren't surprises.  I'm still working on exactly how to turn those attributes into numbers.

Regardless, for the collectables at least, I take my base distance for a level (its size), ratchet that up to increase its difficulty, and point-buy collectable patterns until I've filled my level up.  I use an exponential curve to ramp up the difficulty between levels, so the later levels have more demanding patterns of collectables that require more maneuvering on the player's part to complete them successfully.

The important thing to take away from this is that I'm using a highly mathematical approach to game balance.  I'm picking one value (effective distance) to act as my "hinge value", and calculating the other variables of the system in terms of the hinge value.  I can then use the values of individual elements, expressed in terms of my hinge value, to generate levels that are mathematically balanced from a difficulty curve.

This doesn't get you all the way there, of course.  For one, your assumptions have to be right as to how difficult something actually is.  Secondly, a mathematically balanced game is not always a fun game.  The advantage is that you have at least some basis to work from, and you're not just blindly making changes to your system.  It makes for a decent starting point.

to clarify, i never said the industry is always wrong, just that they can be wrong, and that the industry tends to fund research on small incremental improvements to existing technology, not radical departures, because let's say someone created a 10-base computer. one which could perfectly represent 0.1 without imprecision. who would buy it? who could code for it? nobody, it'd be pointless to create such a thing -- not because there's anything wrong with it, but because it'd be incompatible with everything else

also your base 2 vs base 10 thing is exactly what i was saying. let's say you tell the computer to store the value of 0.1. it would store it internally imprecisely, as steed and bobo mentioned above. in binary, it's stored as 0.000110011... as 1/16 + 1/32 + 1/256 + 1/512... it's an imprecise translation from base 10 to base 2. so computers using binary is *exactly* why they can't precisely store a value of 0.1

ternary computer is different from an analog computer -- analog is a scale, ternary is a bit which can be 0, 1, or -1. the ternary computer mentioned wasn't an analog computer, it was a digital one, it was just base-3 digital instead of base-2 digital

(Obligatory I'm not a EE disclaimer)

They did indeed experiment around with non-binary computers, but the technology for making them is cumbersome, especially as they miniaturize.

Data's represented by electrical charge.  In order to have, say, 10 different values be represented, you'd need 10 different, distinct charges.  Binary, on the other hand, only needs two, "A lot" and "Very little" to represent 1 and 0.  Come to find out, since we have physics to worry about, it's very hard to hold exactly precise levels of charge in computational circuits, so non-binary systems are more error prone.  A program can go very wonky if 5 suddenly becomes 6.  As parts miniaturize, it becomes even harder to hold precise charges, making binary a more attractive option.

At present chip manufacturers struggle constantly with getting transistors that can reliably represent just binary data.  As transistors shrink, we're down to what, 22nm now or something, so does the amount of material that's available to hold charge.  Intel made a big deal out of figuring out how to manufacture "3D transistors", because it allowed them to increase the surface area of the gate, and thus increase its reliability within the same physical footprint.

Sorry for the too big animated gif...

Oh no, the gif is most acceptable

[OBJECTION!]

Mikademus EVADES the Semantic Snare spell.

Maychance metaphors are more useful? It IS possible to overpolish real metal things. Plated metals can be polished until the surface layer is rubbed off and the raw underlying material becomes visible. Perhaps in a similar way the underlying game mechanics in itself can be made to shine through?

OBJECTION!

Judge:  Yes, Mr Edgeworth?

Miles Edgeworth:  Your honor, the defense has simply traded one set of semantics for another.

Judge:  Oh?  What have they traded?

Miles Edgeworth:  Polishing metal is a specific act that results in small amounts of material being worn away, which results in the finish being worn off a piece that is polished to heavily.  It's a matter of physics.

Judge:  Very interesting, Mr. Edgeworth, but this isn't shop class.  What's your point?

Miles Edgeworth:  My point is that game development isn't a physical act like polishing metal.  "Polish" here is a borrowed word, and the connotation that was borrowed is that "polishing makes something better", but the physical consequences of over-polishing weren't borrowed.

TAKE THAT!

Phoenix Wright:  It is the same word, and thus it's possible that the deeper metaphor was borrowed.

HOLD IT!

Miles Edgeworth:  That's quite the presumption, Phoenix, that the entire meaning of the word is carried over.  Well what about the other connotations "polishing" carries?  Maybe then game polish requires a cloth and some polishing compound?  Perhaps a vigorous rubbing motion?

Phoenix Wright:  Well of course it doesn't.

Miles Edgeworth:  Then does it follow that, perhaps, the consequences of "over-polishing" were not carried over as well, and that what is perceived as "over-polishing" is in fact a totally different problem entirely?

*BANG BANG BANG*

Judge:  That's enough for this session, gentlemen.  Let's get lunch.  Court will resume at 2:30.

Phoenix Wright:  Whew, saved by the gavel.  Better review my notes and get my defense ready for the next session.

making the easy mode of my game easier, and making its hard modes harder.

It's better that an easy mode be too easy than too difficult.

Have you gotten anyone who isn't familiar with the game to play it recently?

It might be worth checking out Ace of Spades, which kind of combines Minecraft with an FPS.  It's certainly not an RPG, but I like the genre mashup.

http://www.ace-spades.com/

Learning to program is a marathon, not a 100-meter sprint.  It's going to take years to reach a high degree of competence.  Don't let that scare you off, it's like trying to master any other skill.

Moral of the story is that you need to start small when you're first learning to program.  For many, the mindset of a programmer is something that you have to learn over time.  If you try to jump into the deep end and learn highly complex languages/tools from the get go you have a pretty high chance of getting overwhelmed and discouraged.  There's no reason to set yourself up for failure, or make your life super hard.  Trust me, you're not going to gain anything from it.

Game Maker gets a way worse rap than it deserves.  I've seen people make games waaaaay cooler than anything I've ever made using Game Maker, and it's a good environment to get your coding feet wet if you really want to start off making games from the get go.  Don't be afraid to learn a tool that you'll likely outgrow someday.  The learning experience is valuable, and the knowledge you get from making games in Game Maker will carry over to future game development.  Besides, the reality of being a programmer is that you have to learn and discard tools all the time, so don't worry about it being wasted time.

Pyramid Head.

He has an very strong, recognizable profile, which helps with the generally foggy, indistinct features of the Silent Hill games.  You can see him moving toward you through the fog and you know exactly who it is.

His design in general is very bizzare, and works quite well for Silent Hill.  At first, you're not really sure what you're looking at.  He looks human...but man is his head weird.  The scale and shape of it are super off-putting and settle Pyramid Head pretty solidly in the uncanny valley, which is exactly what you want for Silent Hill.

This sent a flurry of ideas through my noggin. 

Your hands have been viciously stung by a swarm of angry bees and now you must SAVE THE WORLD!!!!

I too agree with making it separate.

If you're generating some sort of file to represent levels (like XML or something), then you can reload levels without having to recompile your game.  I'm not sure what you're developing the game with, but if you use an external tool you have the option of coding it in a separate language.  Things like C# have a lot of good GUI tools out of the box, and are excellent for developing tools with.

I've used Mercurial, GIT and SVN, but it's hard for me to pick a favorite.  I used Hg for my biggest projects and it was quite nice.  Had a good GUI for Windows, if I recall, and juggling a ton of branches wasn't that big a pain.

Thirding the fog suggestion.

In real life, fog gets progressively denser as you look through it.  Objects closer to the camera are easier to see than those far away.  While you have the thick, textured swirl sitting really close to the camera, you're not getting the long-distance thickness, so it looks like you're looking through smoke on the lens rather than fog filling a forest.

Overall though, this game looks fantastic.  I really like your character designs a lot.  Smacks of a lot of the high points of JRPGs.

I still don't understand what Geti said; "push to source control." And while I'm at it, what's HTH?

HTH means "hope this helps".