I had a bit trouble reading through the article, Every paragraph contains about two sentenes which for me bloats up the text.

Maybe it is worth splitting this up in serveral articles, I think you can get more to the meat of things and explain concepts in detail.

I'm against breaking up articles into parts if they can all be combined. It only makes things harder to find for people, and the authors need to make sure to manually link up all the parts so people can jump from one to the others.

That said, I agree that the habit of the author to break up paragraphs every two sentences can make reading tiresome

wwwww

This is a very good article!

I plan on making an infinite game in the future when I feel I have enough experience to handle it. I'll definitely give this article another read when that time comes.

wwwww

wwwww

EDIT: Alright, that should do the trick.

But seriously guys, add a WYSIWYG editor for articles. Doing formatting by hand in pure HTML is so tedious.

I don't disagree but tend to work in ways which wouldn't apply anyway. I write most of my articles in Scrivener because I rough them out just kinda thinking and typing which leaves a disorganized mess. Then I start using the cork board to chop everything up and put it into individual thoughts. Then I finally lay it out in line point by point rewriting for clarity. By the time I get to GameDev, usually it is just a matter of proofreading and inserting images/h1/h2 etc.

wwwww

Sorry to be a downer, but only kids and young people throw around the word "infinite" so lightly. Do you still own/play any computer software from 20 years ago, let alone a game?

When I began your article, I thought you were talking about a timeless game, like Chess, Checkers, Blackjack, etc. and how to design gameplay rules that make a game timeless. That would have been a much better article IMHO.

This article babbles for far too long about things that anybody capable of making a game would already think of themselves. Many of the requirements you list are not even feasible within the scope/budget of a game or could date the visuals/graphics to the point where the game won't even survive its first year.

Long story short, I'm glad you blogged all this onto Gamedev, so you can get it off your chest. Now go and make a game instead of talking about it!

Much like the earlier version of this article, it's all a bit hand-wavey. I'd much rather see articles surrounding specific techniques for procedural genration and dynamic story, than a general article that basically says "this is possible if you try hard enough".

I understand, but the problem with that is that every infinite game will be vastly different.

Specific techniques you're asking for will depend entirely on the design, meaning its not possible to pin-point the solution that works for every situation. It will always differ from game to game.

The purpose of this article is for you to better know what design decision to make when faced with specific challenges. Its about seeing the big picture and having the thought process you need to make the correct desicions to achieve an infinite game.

Do you understand what I mean?

I'd be interested in seeing an example infinite game designed step by step. Not necessarily as part of this article, unless you wanted to work it in piece by piece for each section of the article.

I quit reading when the author advised the use of the waterfall method and warned against iterative or agile development. Assuming perfect requirements is a mistake I have seen repeated too many times in the dev world and games especially suffer from this problem as emergent gameplay (both negative and positive) can frequently emerge. You can plan and design all you want, but you eventually need to start writing code.

wwwww

wwwww

wwwwww

While that is a real thing in game development, infinite games are immune to this issue. The thing is, infinite games are essentially a robust framework for a consistent universe. They are emergent by nature and encourage it.

Oh, c'mon. No project is immune to the problems of a waterfall development model, and quote-unquote "infinite" games are even more liable to end up as vaporware.

Emergent gameplay is an area where the waterfall model falls especially flat. The ramifications of small changes to a complex ruleset are almost impossible to reason about in isolation, and the only effective way to reach a solution is through a process of iteration and refinement (otherwise known as "agile" development).

The fact that you have the hubris to think you can design the entire ruleset of an infinite world in your mind, before ever writing a prototype, is indicative to me that you have never held a significant position in a real-world development effort.

I know this is old but I want to point out something. Well, two things: first, swiftcoder hit it quite well. A game or otherwise large project is constantly evolving. In fact, to suggest an 'infinite game' can never change (in the core or mechanics, without breaking) while at the same suggesting the world is constantly evolving, is nothing short of a logical fallacy. Sorry, but that's the truth: you cannot foresee everything and if it is evolving then it is not static, is it? Just like the universe (the real universe) has new surprises so too does a game (more so than the real, perhaps). Further, I agree that you must have never worked on a large scale game because the fact is, you don't just "write it all up" and well, that's it... cannot change anything, improve anything and all those bugs (that will exist, simple as that) that players have found (including some in the core)? Well, too bad. Cannot fix them as that might break things. That makes no sense at all.

And my point I wanted to make? You suggest competitive cannot work in games of this nature, say multi player games with a vast universe? How come I've done that then? Again, simple: you misunderstand the word competitive and you're forgetting context! Pitting players against each other in every way possible might only work for some games and more importantly some players (but be real: they can work, have happened and more will be created) but who is to suggest pitting players against one another is all bad? What if you are pitting them "against" each other to be better? Role playing game? Well you can give them incentives to being on top of their role playing (see next point). What about something like achievements? Certainly you can have a list of each achievement type and who has the highest (plus they might gain awards simply by an achievement being a currency or having a way to show how much time they invested/how well they know the world/any number of things). And not only does that immerse the players it also encourages playing and playing WITH each other (the achievement part I mention? I did EXACTLY that and it encouraged playing WITH each other yet at the same time COMPETING). Context is important, always.

One more ironic thing that I cannot help but (it is in my very nature) mention (for first, see about constantly evolving world yet cannot change):

You writing about how you have to design very carefully from the beginning and that fact breaking or making the game. Well, guess what you didn't do when writing this? Yeah, you missed some critical ideas (question: is this an 'infinite game' or an 'infinite article'?)