Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Feb 2001
Offline Last Active Yesterday, 10:27 PM

Posts I've Made

In Topic: The Problem With Capitalism

25 September 2016 - 02:14 PM

This thread has devolved into name calling and cherry picking on both sides.

Obviously, capitalism is in its current form is deeply unfair and the cause of great suffering in the world.

Equally obviously, totalitarian communism has spectacularly failed.

But hey, instead of thinking of lessons each could learn from the other system, let's just make stupid points about how poor people are lazy or mortgages are the new slavery.

I think my original claim can be summarized as: "Capitalism is an inherently unsustainable economic system." Agree / disagree?

Fairness or suffering doesn't really enter into the question.

I think it's a mistake of false dilemma to say, "Not capitalism, therefore communism!" because the options/choices for economic systems are broader than communism or capitalism.

I'm hoping to see some good arguments for or against my original claim.

In Topic: I can't buy Digital Homicide Studios games from Steam anymore...

25 September 2016 - 02:02 PM

People like digital homicide give indie developers a bad name.

A gamers idea of what an indie game is has been polluted by endless shovelware constantly pushed in their faces in app stores and digital homicide try to cash in on this.

Have you ever been speaking to a gamer who asks "so what do you do", and you say "I write indie games", to which their reply is "oh aren't they those crappy ones that seem half finished" or something of that nature?

I get this often and it turns out their idea of indie games is those shovelware apps often berated by total biscuit etc.

Also, I worry that the culture of making fun of indie games on sites/channels such as Jim sterling discourages a lot of indie devs from being more public about their release.

Just my two pence worth...

Well, we indies have the power to change that perception :) I think the key is to not put out garbage, but to continuously develop and refine a product until it's perfect. The indie advantage is that we can handle risk better than AAA studios, so we can afford to be more creative and innovative with our games. If we don't do that... we're just making reskinned copies of existing IP and nobody is interested in that.

In Topic: The Value of Procedural Generation

15 September 2016 - 11:27 PM

One aspect being missed from the above is that procedural generation cuts costs. It makes things practical that were not otherwise practical for the same team. It is certainly possible that - replayability aside - 20 hand-designed levels could be more interesting than 20 procedurally-generated levels, given the same designers being involved in both cases. But it's not possible that, assuming a competent code team, the 20 hand-designed levels could be made in the same space of time.




Or, hire a hand full of designers and have them build about 40 maps, then let players choose a map to pick. Again, loads of *cheap* replay value.


I'm guessing from this statement that you have never hired a designer. :)  They are cheaper than coders, for sure, but not so cheap that getting them to make 40 good maps is 'cheap' compared to procedurally generating them.




just hired a couple people to hand design 5 different planets in the same star system [...] It would have been the game everyone dreamed it would be.


I don't know who you've been speaking to, but I don't think there would have been even 10% of the same interest in this game if they'd said "you can explore 5 hand-crafted planets". As for factions and multiplayer... that was never what it was about. EVE Online exists for that sort of thing. If you want to understand No Man's Sky you need to understand the history of games like Elite. It doesn't gel well with the modern heavily guided theme-park experience, but that's a failure of marketing and the runaway hype machine more than anything else. I know people who really enjoy the NMS gameplay for what it is, like they enjoy other open-ended and exploration-focused games.




Let me approach this from another direction. There's still a belief that procgen is somehow replacing designers when really it is about freeing them up to work on higher level aspects. Exactly the same thing happened with the art pipeline. Go back about 25 years, and artists had to place every pixel themselves. Later, they might model a character in 3D and render it out as sprites, so they would only edit pixels to clean up a render, perhaps add detail, that sort of thing - the rest was handled by the lighting and texturing algorithms. In 3D engines, it's gone even further - the artist might produce the model and the texture maps, but they don't get any control over the final pixels on-screen - they just have to trust the algorithms will render their data in a way that works for them. But freeing them from pixel tyranny means they can be more productive in other ways - changing one texture will improve multiple assets. One animation can animate multiple models. Altering a light value will affect the whole scene, environment, props, and characters. Artists gave up some fine control but can now deliver whole 3D experiences with far more content in them.


Procedural generation is the same thing for designers. Instead of designers hand-placing every wall or door, they should be able to tell the system how walls and doors should be placed, and the system does the work for them. If they build a room and want to fill it with props, they should be able to have the game auto-generate appropriate props based on the type of room. If they designate an area as a dangerous forest, the game should be able to populate it with outlaws and wolves without anyone needing to go and drop in spawn points or planned encounters. If the designer knows that orcs and elves hate each other, the system should be able to create quests based on this antagonism, without requiring a designer to manually place each scripted event and write every bit of dialogue. The tools can amplify the designer's ideas, not replace them.

Good points. I'm looking at this from the producer angle where you have to make a trade off between designer time and coder time for procedural vs. non-procedural game design. Creating a procedural level building system will cost programmer time, and the amount of programmer time it's going to cost is dependent on the design requirements of the procgen for the project. Some implementations can be relatively easy and straight forward. Others, like NMS would take a VERY considerable chunk of the project budget to correctly implement. The project resources are finite, so making a decision to spend a lot of time on a procgen system will have an opportunity cost on other aspects of the game. What is NOT being built, designed and refined because you're spending thousands of man hours building a sufficient procgen system?


If you put on the producer hat, you have to start asking some hard questions about where the best places to allocate effort are, based on the resource and time constraints you have. I think in the case of NMS, they did a great job with the procedural world generation. It's state of the art, no doubt about that. But, the game play is currently very flat and uninteresting. So, if I was the producer and I could wave a magic wand in that game, I'd commit at least another two years of design and development to build out rich game play mechanics to give the game the proper depth it needs. My prior post was trying to imagine what some of those embellishments could be. I can imagine that the executive producers and investors funding the project probably didn't have much patience left with extending the development timeline further, so the dev team probably faced a lot of pressure to finish what they had and ship the game as is. No producer has a crystal ball and can foresee these kinds of project woes a few years in advance, especially when project requirements are ever changing, and timelines slip, so it's hard to make the correct project focus and adjustments early on. I think there's a sweet spot on just the right amount of procgen, and too much, and not enough. The question to ask is how and when to identify when there's too much procgen and the risk to the project production, scheduling, and opportunity costs. What's the leanest way to get the same effect of procgen with the most efficient staffing vs budget ratio? As you said, designers are cheaper than coders, so it might be cheaper to hire an extra pair of designers to tackle a project need than to assign a few coders to it, but that will also be a function of the scope of the project need. 18 million planets? Definitely want to procgen that stuff if that's what you finally commit to.. But, let's back up a bit and revisit the requirements. Why do we need 18 million planets?! What's the underlying requirement we're trying to satisfy? How many planets could we get away with and have the same design outcome? What's the dollar cost difference? How much time would this cost? What if we do procgen for 50% of the easy stuff, and leave a designer to fill in the other 50%? Or, what if we do a 75% procgen implementation and 25% designer implementation?

I'm not saying "Don't do proc gen at all", I'm saying "Be very careful when you think about the actual time and resource costs this will incur on your project, because your resources are limited and you may do this at a cost to other parts of the game, which ultimately ends in a launch failure like NMS." A producers job is to mitigate project risks, and this is an interesting, new risk to take mitigating steps towards :)

In Topic: The Value of Procedural Generation

13 September 2016 - 11:27 PM


The litmus test is to take away the procuderal generation aspect out of your game, play it extensively, and ask if its still a great game without it.


Hmm... I'm not sure about this.


Consider the "roguelike" genre: Would a roguelike be much good if it relied on levels that were purely hand-crafted, resulting in the player exploring through exactly the same set of rooms on each run? I doubt it--intuitively, I imagine that most roguelikes would become boring if the levels were the same on each run. Now, one might argue that this should simply imply that roguelikes aren't particularly good games--but they seem to have a fair following, implying that a reasonable number of people enjoy them. To my mind, this implies that they likely have at least some virtues. If I'm right that they would become boring with static levels, I argue that procedural generation is one of the virtues of (most) roguelikes.


I think that, as I believe someone else wrote earlier in the thread, procedural generation is a tool: it can be overused, used to poor effect, etc.--but I hold that it can also be used well. And yes, I think that it can be a central feature--as in roguelikes.


This is a good question, and I think it's testable. So, how do you test a roguelike game without procedural generation?

Get a brand new person who has never played the game before. Load a level. You could even do this as an blind A-B test, where you push a button and one person randomly gets a procedurally generated level and another gets a designed level, or a preset level. Now, they play the game for the first time. Because its the first time, any merits of a procedurally generated level are wiped away (variety in replayability). So, now you have to ask, "Is the game fun or boring?". If you add procedurally generated levels, all you're doing is adding replayability to a game which should have a core game play mechanic which isn't the procedural generation. If the game is fundamentally boring, then no amount of procgen is going to fix that underlying problem: congrats, you can now create ten million boring levels. If the game is fundamentally fun, then the procgen is not the core element of the game play, but it does add replay value.


I'd much rather have a game with 1 level which has a really, really fun game play mechanic. The developer nailed it. The game is deep. It's interesting. Whatever they did, it's fun and working. The developer spent most of their project "budget" (time, people, resources) generating this fun game experience. Great! Now, hire a level designer for three months and have them design five large levels, randomly pick a level when the game starts, and you've got replay value! Or, hire a hand full of designers and have them build about 40 maps, then let players choose a map to pick. Again, loads of *cheap* replay value. A lot of RTS games do this quite well.

On the other hand, some companies spend most of their project "budget" working on building robust procedurally generated worlds. At the end of the project, you can say, "Great, the worlds look convincingly different! But... you spent your whole project budget developing this part of the tech instead of building a deep game. You've got thousands of hours of worlds to explore, but three hours of interesting game play before it gets boring and tedious." Just think, what if No Man's Sky had spent 90% of their project budget making the core part of their game REALLY fun, skipped the procedural world generation all together, and just hired a couple people to hand design 5 different planets in the same star system, and they created a multiplayer element where players join factions and battle for control of territory on each planet to control precious resources? And you can craft things and build houses. It would have been the game everyone dreamed it would be.

I now think that heavy procedural generation is a trap. It's easy to get excited about, but it wastes time and is inferior to a carefully designed set of levels / worlds.

In Topic: The Value of Procedural Generation

12 September 2016 - 06:22 PM

I think we need to backup a few steps and ask some questions regarding procedural generation:

1) How much engineering time will it cost to develop procedural generation which is indistinguishable in quality to a hand designed world? How much designer time would it cost to get the same or a better result?


2) How much value does it add to the player playing the game? If development resources are a fixed asset you can spend, would the player get more value out of a game designed to be deep but narrow, or a game designed to be shallow by broad?

I think we can look at Spore and No Mans Sky as examples which inform our answers to these questions now. Without those two games, our answers would have been more difficult, so there is great value in these games and looking at the mistakes they made.

I think at the end of the day, it all comes down to giving players a rich experience. We have to be very careful in how we define "rich experience", because a world with infinite objects to interact with doesn't necessarily make the world "rich" if the experience is universally the same. We have to look at what makes the game "interesting" and develop the game to be that: interesting. A game isn't interesting just because the worlds are procedurally generated. A game gets interesting when there's interesting things to do and think about in that game, and a procedurally generated world would just be the scaffolding upon which a richly designed game system rests upon; The procedural generation is pretty much irrelevant as far as I'm concerned. If you have to say "procedural generation" in your marketing pitch and value proposition, you're doing something wrong and either your pitch needs work or your game design needs work. The litmus test is to take away the procuderal generation aspect out of your game, play it extensively, and ask if its still a great game without it.