Procedural game development?

Ok so, in my current project I've found myself developing more automated tools to help me to save time later. I'm not creating a procedural game, ie at runtime it's not generating randomized level layouts or whatever. But I've found benefit in creating procedural stuff on the development side.

So for example I needed to place some objects in the scene, and quickly saw this was going to take a lot of time, so instead I wrote a basic tool that let me sort of 'draw' multiple objects at once and connect them together and stuff, saving me a ton of time. That then gave me insight into how the process was still quite laborious and how it would be useful to have some additional higher level automation, so I added that. Not getting to the point of procedurally generating the whole thing at development time, although that's not out of the question, but at least moving towards a significant amount of automation to help make development easier. It's nice to have the 'right tool for the job'.

Question is, by doing this and creating automation tools, turning the development process into more of an automated/procedural generation of game data, does this maybe interfere with the design of the game? Is there a point where too much automation might lead to a badly designed game? As with creating procedural outputs at runtime, creating procedural outputs at development time has the same dangers of creating ugly results, boring results, impossible results etc. But I at least see that spending some time 'sharpening the axe' can have a big payoff in terms of having to cut down a lot of trees quickly.

 

... But the whole point of doing it during development is that you can keep hitting that generate button til you get something good. It's also good to build manual overrides so you can control fine details.

Just consider proc gen systems like an intern. The only way it can make thing go to S*** is if you don't oversee what it's working on.

 

Probably depends on how you do it.

I have an idea for a game which is based almost completely off of procedural generation. The level is generated procedurally at runtime, and everything else is built based off of the level's topology/user settings.

This means there are no or very few constants, so creating a setpiece-heavy (or perhaps narrative-heavy too) story for instance would be impossible. Look at No Man's Sky's "story" for an example of how that might work.

But I am also using it to create a level in the editor, then using that level for a different, more focused idea. So I'm using it initially, but custom-designing after that. So in that case it doesn't hinder very much (though I DO have to add some stuff that Unity can't naturally handle, like caves).

 

It's all about how you use it.

Used well, you can scatter objects to give starting point then carve out your game from it.


Used poorly, and well...

 

Your second example is likely not to do with procedural development, since all those planets and stuff can't be stored on disk as such, they're generated at runtime?

 

I believe they use a seed for the planets so it would be procedural and you could save it.

 

I guess I misunderstood what you were saying then.

But if you're saying that unless you have 100% control over the placement of things then it could potentially be poor results?

I mean, I don't edit an image pixel by pixel, why would I make a map tree by tree or rock by rock?

 

Well, like other people say, it all depends on how you use it. For example you could spawn asteroids on an exact cube grid and it would be boring, or you could spawn them in an ellipsoid pattern with bigger ones toward the center or something like that. Then it actually looks like it might have been a planet or something at one point, and starts being a little bit interesting.

There's literally no way to give you a rational answer without context. 'Procedural' can mean absolutely anything. Until it's defined, I usually treat it as a buzzword when I see it around here and start spamming the thread with .pdf's in an attempt to get more specific (to no avail).

If you want to spawn trees in a 50km x 50km terrain, then I would say 'absolutely procedural is the way to go'. If you want to spawn stories and missions I would suspiciously ask for more detail

 

@Billy4184 - I definitely get what you mean. I'm making a procedurally-generated game where the levels are procgen. I toyed around with the idea of procgen quests and storylines, but it's a pretty massive venture. I also see a lot of people say they want to make "procedurally generated" content without really understanding what that means, and what it entails to do well (at least, in part, a significant amount of play-testing).

The OP's concept of procedural development is really a great thing. Using procedural tools to create static worlds can make level design significantly easier. The question, however, has nothing to do with content being procedurally generated or not (even if presented as static). A game is good or bad in it's own merit, the tools used to create it are rarely to blame in either direction.

 

As I discover my current game is increasingly telling me, "I'm best as a handcrafted game. Dont procedurally generate me." due to the likely lack of replayability, I am stuck in a development which has all the tools for procedural generation but without the need for them.

Being a jerk (including to myself) I jumped to contemplate of I wasted all that time like some idiot. Damn you, Carter! Inefficiency!!

Quickly I began to realize how great of an idea this would be; I can use these tools to generate a good start for handcrafted content & even extend the tools slightly to regenerate individual pieces of content; in case "It's all good, except over here in this small corner."

Then I began to ask myself, "What is the difference though?"

While procedural generatiom has that chance to create horrible content on rare occassion, that weakness is eliminated in this new context. I just hit "Generate" again.

Without any tangible way to measure my skills as a level designer, how do I even know what looks good or bad? What if I am tone-deaf (unable to see difference between good/bad). Who is to say my handcrafted content would even be better than a good set of procedurally generated content?

Furthermore, are my skills as a level designer a great enough of a difference over procedural generation to justify the enormous time sink required for me to hand-edit my levels?

Now that I dont need procgen, and since I am not a renown level designer, what is the real difference? There is no big difference. However at least by picking the procederal generation I can guarantee no "rare horrible content". And static scenes now give the added benefit of spending as much or as little time as I want polishing areas. A delete here or there to tidy things up when I'm burned out on coding for the day perhaps? My game would still be better than ot was before, so isnt doing NOTHING besides hitting generate a few times better than before in a low replayability game?

And most importantly I think the better question is, "What benefit is there to the highest quality level design?"

Do these experienced level designers who theoretically place EVERYTHING themselves actually make a big difference?

I'm not sure I've ever played a procedurally generated game where the levels were, on average, trash. Always are there bad cases, but on average? I've been just as satisfied as any game with a team of seasoned designers. In fact, I often appreciate the random nature MORE from a computer than humans so normalized to certain tropes that I can predict secret areas or roll my eyes at a puzzle.

Of course my wife is different. She is an artist, so the tiny details placed by hand are things she really enjoys. And she likes thinking like a designer, "Where would I put a secret" and being rewarded for the educated guess.

But those are things you can add AFTER generating content with a tool. They are also set pieces you could insure get placed in purely generated content. So I question the usefulness of a professional level designer nitpicking where each tree gets placed, or how to setup a beautiful entrance from the West in a game where 3/4 players will enter from the East North South.

That is alot of time wasted placing rocks.

Unless of course it's something like a Point & Click. Then procgen as a tool sounds as ludicrous as procgen as a game system.

 

You have some good points. However, it can be difficult to get a computer to do what a human can do. Like, just, to be imaginative, or to create complex puzzles, or to have a sense of what is 'fun' etc. You can create a lot of stuff, take Spelunky for example, it's largely procedural based on some rules and templates. The time saving from procedural generation is HUGE. But it still somewhat falls short of the quality and intelligence of a person hand-designing something or creating a work of art. BUT, as you point out, if the person is just going to be making the exact same kind of decisions, and grunt work, that some kind of automation could do, then why not automate it.

 

Theoretically, yes. In practice, i'd think no.

Theoretically, you could assume that spreading out rocks and trees with exquisite artistic expertise over a large area would produce better results than just using a proper algorithm and having it slap down the rocks and trees. In practice, you'd save a lot of time by automating most of the area and doing select points of interest by hand.
It's just rocks and trees after all.

Some puzzles are perfectly fine to be generated by an algorithm, ie Sudoku.
While puzzles that dont follow set rules obviously require a human brain.


Since NMS got mentioned, i dont think NMS would have been better if they had designed the landscapes by hand. It wouldnt have made a difference. The gameplay was bad, barely existent really. Their landscape generation was fine, but if all you do is look at landscapes and mine rocks... well... i can look at landscapes here and i dont even have to mine silly rocks to do it.

 

OR here

Which make the case that either:
1. Curation is art
or
2. Art is curation

Anyway, in order to have a good PCG you must be good at doing what you want to generated first, it's a requirement to create the set of rules that will curate the possibility space. If you create a set of rules from an amateur perspective it will produce amateur works, it's not magic. And designing the algorithm would take as much time as designing a similar set of assets, to have diversity you need to craft as much model as type of asset function needed, which take time.

 

This seems interesting:

http://www.gamasutra.com/blogs/Grah..._Generation_in_Unity_for_MERC_part_2_of_2.php

 

Hi everyone! Probably, my post is out of discussion... but I hope to hear from you. I am new to the games world but wish to try. I found out that it is possible to create own Minecraft server and I thought that I wish to try it. In the end it will be good experience for me being a new in the games world. Do you know where I can find out the structured info about it which is easy to follow? What do you think about that kind of idea?
My apologies once more that I am out of topic. Was not sure where to post such question.

 

Am I understanding this correctly, you're new to gaming and want to have your own Minecraft server to play Minecraft online? If that's what you are looking for and you want to only play together with friends, then this might be a decent solution for you:

https://minecraft.net/en-us/realms/?ref=m

If you want to rent a "real" public server that is open for all players, then you should google something like "minecraft server hosting" and choose a provider that is geographically reasonably close to where you live. E.g. if you live in the US it would be a very poor choice to rent a server in Europe, because you'll have a bad connection to the server, also known as "lag".


If I misunderstood your question and you want to create your own game from scratch as a kind of minecraft clone, then you should start with all the tutorials on https://unity3d.com/learn and keep working hard at learning for quite a few years, because making multiplayer games is incredibly complex and you'll have to start with simpler things first.

 

Thank you Martin_H for your quick reply. Yes, I am new in gaming and wish to have my own Minecraft. Also, thank you for the advice about "real" public server. Does server depend on the geographic location or should I consider something else?

 

I don't know much about Minecraft servers myself but I recommend you go to this forum:
http://www.minecraftforum.net/forums/servers/minecraft-server-hosting
That is their forum-section for Minecraft server hosting providers. There you can directly talk to people from various hosting companies who can answer your questions. Check some of the threads of the more popular ones and see if there's one that people describe as simple to set up, and check if they maybe have a tutorial video that shows you what you need to do.

 

Thank you Martin_H for your reply and for the link.
I know that it is still to early for me to ask about the game development procedure because I am completely new in gaming but it is still interesting to know how to come to that stage in one day. Do person need to complete the special courses to get the all knowledge to create the game or it is enough to have a self training?

 

Years of dedicated self training are usually enough. https://unity3d.com/learn is a great place to start learning how to use Unity. https://www.youtube.com/user/ExtraCreditz is also good for beginners (for example their video series on making your first game), but their videos usually don't go very deep into topics. GDC talks are a great learning resource too:
https://www.youtube.com/channel/UC0JB7TSe49lg56u6qH8y_MQ/playlists

 

Thanks you for links! Already started to watch some videos.
By the way, what do you think about this advice to the new game developers

I watched it and thought that it is kind of straight forward thing or I do not get the main idea...?

 

Personally I think people who after their second failed "big project" still keep planning for even bigger projects will never make it, because they lack the ability to learn from their failures.
"Start small" is good advice. But his extrapolation to get to where you have released half a dozen games and now have a team of several people working for you is oversimplified to the point of no longer being really useful as advice. You don't just "get" people to work with you. Unless you can afford to pay them a professional wage, you'll most likely be on your own. Finding partners that work well with you and are willing to agree to insanely risky revenue-share deals to work on your game, is a very rare thing to find. Financial success from making games, so that you can hire people to make more games, is also a relatively rare thing to achieve. For every game that made it big, there are hundreds, if not thousands, that were financial failures.

 

ok, now I see... it makes more clear why "start small" is better approach. Thank you!
Also, do the new game developers usually create kind of similar game to the game which already exists or they bring something new to the market?

 

I'm not Martin_H but I can answer this one. It's typical for folks still learning how to develop to make games which already exist, just to learn the basics. One example is "make Pong."

 

Thanks! will definitely try it during this week.

 

I tried "make Pong", it was definitely a good thing to try. Learned basics, did not struggle that much. It is already great sign for me Thank you once more for the advice.

This weekend finally decided to set up Minecraft server... at least to try.
Probably, my question is super silly but what does it mean by saying a "dedicated root server"?
As I understood, it is the first step to make a multiplayer Minecraft...

 

This thread is severely derailed.

 

Well it's up to you to get it back on track. Go!

Edit: related: https://forum.unity3d.com/threads/archimatix-a-node-based-parametric-modeler-for-unity.330869/

 

So to discuss procedural stuff some more...

I think the real benefit is the lack of stress.

Let's say you need twelve villages to go in your open world. You can tell your artist "make me twelve villages," and he'll go work like hell to make twelve villages. Then he'll show them to you, and you will tell him to fix this one or that one, and you'll iterate. Meanwhile the deadline looms and you still aren't happy and your artist is starting to work later hours.

Or... your artist can type "2500" in a text box and click "make villages," then go to lunch and come back to find 2500 crap villages waiting for him. Then he can start going through and deleting the ones that really suck, until he has about fifty that he thinks could be made into something worth having. So he brings them to you, and you say "ooh, this one and this one and this one and this one and..." until you have twelve. Then he sticks the rest in a folder somewhere and works on those twelve.

Under which circumstances will your artist be more relaxed and groovy, leaving him in the best headspace to be creative?

There's honestly no substitute for a good artist with strong design sensibilities. But you can sure as hell give him a procedural assistant.

 

Or you know, while fixing the crap village he can explain to the designer who made the village algorithm what to fix until it makes better villages. There is a great chance that all 2500 villages will be crappy if the proper design aren't implemented (for example it's unlikely that they will exhibit high level composition necessary), sophisticate order don't just emerged emerged from pure randomness, it's in theory possible, but noise generation don't generally stumble on mona lisa unless you have implemented principle of composition and anatomy.

Also Horizon zero down used runtime pcg for its environment, stealthily, but they made a gdc talk about it.

 

That would be where the development manager goes to the project manager and says "tell the damn artist to stop bothering my developers."

In the real world, you don't usually stop developing because you can't make it better, but because you don't have time.

 

But having a pcg is all about saving time if you get it right (or good enough) first you get multiplicative effects, in fact it's happening, most people in the industry are moving to pcg workflow and stealth pcg workflow. Horizon has pcg because it save time (less designer tinkering, less data to stream, smoother perfomance, less bug, less polish to add), speedtree is pcg, house in assassin's creed is pcg, animation in for honor is half pcg, witcher and swotor has pcg cutscene, they save time big time.

 

Yes, and you've hit the wall on that. Follow along here.

A human level designer can generate, let's say, five concept sketches a day. And two of them are good enough to develop further. Each of them takes one more day to develop, and one of them ends up being good enough to work into a final level. You need twelve levels, that's 36 days and then the designer does the final work.

A procedural level generator can generate two thousand concepts a day, and fifty of them are good enough to develop further. Each takes one more day to develop, and half of them end up being good enough to develop into a final level. You need twelve levels, that's 24 days and then the designer does the final work.

Using pcg has saved a third of the time in level creation, which the designer can now use to make the twelve levels you need better. That's good.

If the level generator could generate five hundred concepts good enough for further development, this would not save any time. It would just produce more trash. The designer is now throwing away 450 more levels. You have used up the designer's time explaining what to do, and the developer's time doing it, to produce nothing of any value to the project.

In fact, since choosing 24 from 50 is less stressful than choosing 24 from 500, the new better pcg is making the designer's job worse.

 

I think by that point you would have something solid enough to just trust the generation, which is the point. By knowing exactly the weakness and the strength of the generation you can precisely look for them which reduce the strain.

And a pcg wouldn't be generating concept, it would generate production ready implementation to check. So you save time because you just skip a massive amount of the process, I mean a level might take 1 month from concept to implementation, you have 2000 of them in a days, it's likely you will have generate meta data to have a good quick overview (like highlighting critical path, using heat map to visualize encounters) which allows for quick checking ... You better have them great directly with minor adjustment rather than having to spend time correcting.

And to do that you can also put constrain so it explore only some archetype instead of randomly stumbling on what you want, so you only check rural town in a valley using concentric organization rather than having the procedure run wild from the entire gamut of super solenoid civilisation to grotto complex neanderthal city.

In fact that's what we already do, thing like natural landscape are generated and we use broad stroke and curves to signify intent (painting zones) and then eventually populating what's way too specific for the generation to figures out.

Save from generating the story, we still would have to do some handpainting, only because we are the holder of the vision.

 

Go back to the OP.

"Not getting to the point of procedurally generating the whole thing at development time..."

The question as I see it is where you draw the line between pcg and manual effort, given that both are necessary.

Presuming that you can eliminate one of them almost entirely renders the question pointless.

 

It's true I was reacting to the trailing part of the discussion

At some point some concept need to be generated by hand (the vision), even at 2000 maps per day. That's what I was trying to get at, selection can be seen as manual labor, tool don't replace vision, automation don't make bad art, bad vision do it. Good tools don't make better art, bad tools with great artist still lead to great art.

So my answer to op is simply that, automation should liberate your vision and you must spend time making judgement by knowing what you really want. Doing some map by hand will only help you make better automation, they are not mutually exclusive.

A lot of people try to use execution as a replacement for vision. But most great artist had an army of assistants anyway, machine is just the new assistant. Instead of spending time refining the final map, you will spend time refining the pcg to do whatever you want, the automation IS the product. And you can still correct it by hand.

 

Yeah. That's the algorithm. It didn't fall out of the sky, someone wrote it. And that someone was an engineer, not an artist, so it doesn't make good art. No matter how good your artist is, he has to filter his vision through the engineer to get the algorithm, and only so much of it gets through. So the algorithm can only be so good, because you have the people you have, and hiring new ones is time-consuming and expensive, and you only have so much time and money.

Of course, maybe you have hired someone who is an amazing artist and an amazing programmer, and as long as we're dreaming I'd like a pony.

 

You are making a lot of plausible shortcut that have no bearing in reality, there is tool for that and artist has being doing it since forever before even the invention of computer, PCG isn't a new idea, even mozart made an almost procedural composition (though it was recombination through dice).
http://explodingart.com/jmusic/jmtutorial/MozartDiceGame.html
Also Brian Eno, David Cope, Harold Cohen, etc ... Artist really didn't wait for engineer at all, Processing has been abused by artist to make similar stuff for years, and now substance and shader have node base interface, I'm only naming entry level stuff. Just on unity the recent archimatix open some door. In a talk uncharted's dev showed the difference between artist and engineer solution and the artist solution was better and simpler, going through engineer was oly messing thing up.

We can't just go Ignoring history and legacy. http://www.creativeai.net/

By concept I mean you need a starting idea.

 

I don't even understand what you're trying to say anymore. I'm just providing one plausible example of how even inferior pcg can improve the productivity of an artist. Oh, gee, all these other artists used inferior pcg before computers were even available? Looks like I'm right. What's your point?

 

Then what was your point into misrepresenting pcg as being filter only through an engineer as being a problem? I didn't just say that they didn't use computer, I show that it has a legacy of being artist driven, not engineering driven like you imply. Also many of them where actually ahead of their time (and not all of them didn't used computer), we are rediscovering their principles to implement. Computer increase the output but the principle stay the same.

I mean why involve dream of pony if you are not even aware of the legacy. The major problem behind PCG is lack of education and cultural barrier, not talent, once that barrier is broken, getting up to date is rather fast (and by that not just using the same old perlin terrain and random distribution without any thought given). The reason I'm arguing is to make sure enlighten understanding of pcg is spread. The field is moving fast, it has a renaissance, so sooner than later it will be generalized and those discussion will be obsolete.

Anyway I'm out of the discussion I think you are arguing in bad faith.

 

That's not what I said. I said the tool the artist is using in my example was written by an engineer that the artist told how to generate levels. Because the artist is not an engineer, he didn't explain perfectly, and because the engineer is not an artist he didn't execute perfectly. Accordingly, the tool in the example has limited functionality and cannot be appreciably improved.

This isn't an argument. I gave an example. That example is what it is and it will not change. Regardless of how many other examples you can pull out, my example will still be the same example.

 

If I misunderstood I apologize.

 

I'm still trying to understand what your objection, if any, is to the example.

I mean I'm basically saying that even bad pcg can improve your workflow enough to be worth using. You seem to be arguing that pcg does not have to be bad, and that good pcg exists, and it has been around a long time... but I don't see how that matters.

 

It sounded to me like you were universally saying that the procedural generator is made by an engineer, while the criteria are set by the artist. But I think neoshaman was saying that the artist is actually the one "making" the procedural generator, so you don't get the disconnect from translating between an engineer and artist.

That's kind of how it is for me. I'm using TerrainComposer to generate terrain procedurally, and because I'm both the one who knows what they want, AND the one who's molding the PCG tool, I can get what I need (in theory, only in theory--a lot of tweaking is necessary) just as accurately as if I was hand-building it.

 

You can't universally say anything. All you can do is circle a part of the possibility space and describe it. That doesn't mean anybody needs to go sit in the circle.

 

Anyway the future is approaching fast:

https://thenextweb.com/dd/2017/02/22/transform-doodles-cat-monsters/#.tnw_547tlnBA

 

I had a game idea that basically revolved around procedural stuff.

Your in a randomly generated voxel prison, and must escape somehow, or if you want to, just have fun. You, and all inmates are randomly generated (characters with random features anyway) and the layout of the prison and weaknesses and such are randomly changed each game. You randomly have strengths and weaknesses as well, such as how strong/tough your character is, how high they can jump, how much they can carry.... not quite Diablo level statistics but some basic stats that are evenly balanced.

Then as you play, characters have random backstories (semi random chunks of pre-decided info) that make them either like you, hate you, so on and so forth... all "procedurally" (aka randomly) decided each game. You might work your way out politically by helping certain inmates or staff, or you might just kill a guard and go on a spree trying to fight your way out... or you might peck away at the wall in your cell with a fork... who knows!

Anyway.... probably won't ever make that into a game haha

 

Afaik not procedural, but might interest you anyway:
http://store.steampowered.com/app/298630/

 

It has workshop support, so perhaps there's an opportunity to bolt on procedural from the user end.

 

A game that could have been great, but seem to be developed by some pretty incompetent developers. While I could give this a lengthy review, I cannot express the magnitude of failure and horror that is their cheap 'walking dead' version. Such an obvious pandering to try to grab quick cash... really disgusting IMO. The game is so bad too... so 'tacked on' even though TWD has nothing to do with breaking out of prison. I loved the concept and art of The Escapists. Hated the execution, some of the programming, and of course the severe game-destroying flaws that held it back. Would love to see a GOOD clone that actually encouraged you to breakout any way you wanted, rather than restricting ways instead of just making it harder. And for the love of God will these developers stop with the grind. Even good developers like darkest dungeonn didn't learn the lesson of grind until far too late (but they're awesome for addressing their game's biggest flaws and releasing updates and alternative modes specifically to address real complaints.) Unfortunately those types of devs who commit to quality are quite rare. So many, like The Escapists, just want to get a quick buck & only do what profits them the most. Which sadly isn't fixing their games.

Anyway just saw that link and had to say: ewwww no. The Escapists is good as a lesson in how to ruin a great concept or how to achieve mediocrity though. And The Escapist TWD is a lesson in how to ruin your franchise by trying to cash in like a jerk. So much potential wasted...