|
Spatial posted:FMOD already has a priority system which handles that automatically based on overall audibility of each sound. You can offset it manually too.
|
#
?
Apr 18, 2013 22:39
|
|
|
|
| # ? May 25, 2024 16:46 |
|
|
I've got to figure out how to make some UI without losing sanity on it. Consider I know very little about programming and doing this in C++ using the libtcod library. The problem I have is that it'd take me a million of years to finely code the UI as I'm doing now. See this:  It's no more than what it looks like. A menu with three options. Still quite a bit of code. This is the main cycle I made to build it: code:Basically, I have "menu_1()" that returns int values depending on what sensible key is pressed. And "draw_menu_1()" that takes the number of the selected option and that contains the print functions. Built on a switch, so that each of the three cases prints correctly the white highlight effect. I'm not sure if this is more or less what everyone does when making a simple menu, or if my code is quite stupid. The problem is that all this code is specific. It contains a main loop and has to handle everything that can happen. It works, but the problem is when I have a MAIN game loop that ALSO has to handle these sorts of menus and UI items when they are needed, all part of that same general loop. So, any tips on how to do all this in a saner, more straightforward and simpler way?
|
|
#
?
Apr 19, 2013 02:16
|
|
|
I know there are a few UI libraries out there already, but it wouldn't be difficult to code your own. A simple linked list of classes with screen coordinates, size, and a label would handle a menu like that. I wouldn't get too bogged down in that with a roguelike though. Start with the map and some basic game elements hard-coded for the moment, then fill in loading screens and menus later.
|
|
#
?
Apr 19, 2013 02:37
|
|
|
I just want to know how these things are done usually, since what you see there is just what I could figure out on my own. I need menus because I need the handling of different parts now. This thing already supports a basic map with rooms and doors. With the skeleton of turn based combat based on a number of action points. But all this is done through specific cases, so my main game loop is getting incredibly long, and the turn based combat becomes a loop happening within the main game loop, so it's basically a completely different loop that is closed when combat is over, going back to where the main game loop was left. So every little thing I add, I end up creating another loop, nested somewhere. And soon enough I can't track anything anymore because each of these are special cases, while I need to give control to the player so that each component is used when it's triggered (which means that the combat loop has duplicated functions handling the keyboard, drawing the screen and so on). It's just getting chaotic and I need to figure out how things are done by people who actually know what they are doing. The next big hurdle is to figure out how to generate an interesting dungeon instead of just rooms and corridors that look all the same. Sadly I can't find any decent guide on advanced dungeon generation.  
Abalieno fucked around with this message at 02:57 on Apr 19, 2013 |
|
#
?
Apr 19, 2013 02:52
|
|
|
For simple user interfaces in games, "immediate mode GUI" is a sane and frequently-used approach. Compared to conventional GUI libraries, IMGUI libraries are usually not as well-supported or featureful, and quickly get out of hand if you try to compose a complex interface out of them, but are a much more flexible and easy-to-use tool for smaller tasks, and usually integrate very smoothly into the structure of a game. Google might reveal that somebody has made an IMGUI library designed for use in whatever graphics library you're already using (SDL, SFML, etc.), and I believe Unity's built-in GUI is immediate mode. Of course, nothing can stop user interface code from being very long, and managing the complexity of your main game loop is important. To keep it from being just one huge monolithic function of nested decisions, there are several strategies, each of which has tradeoffs of its own. I'll give you a basic overview of a few common ones, but following up with further reading elsewhere. Any game is going to have to deal with the fact that most of its parts have different behaviors depending on their state. The use of finite state machines would be reasonable, though there are many different ways to implement those. In most games, every different state the game can be in is a "scene," and each scene has its own update and (sometimes) render function. It's up to you to decide how far to take this, but try starting with having the main menu and each level be a single scene. You will probably want your main game loop to be responsible for transitioning between scenes and managing which ones are currently instantiated. Structure your code so it can be reused - if most levels have basically the same logic and rendering, have them inherit or call the shared functionality rather than reimplementing it each time - and you should have an easier time keeping your code orderly. Each scene can then itself manage the state machines responsible for each of the elements of the game. It's state machines all the way down. State machines can be implemented in many different ways. If you're working in an object-oriented language, you'll probably be better off implementing each scene as its own singleton class, whereas game elements that need to persist a lot of data between frames make more sense as just objects. Since the state of your user interface probably does not need to preserve a lot of data, it's possible to implement each state as a function (delegate, function pointer, whatever your language calls it). And I'm currently working on a project where, just for fun, I've implemented states as coroutines consisting mainly of nested infinite loops - that might be a bit esoteric for a beginner. More complex games typically use an "entity component system," and in fact Unity gives you one of these for free, but implementing one from scratch would probably exceed what a single amateur game developer is capable of (or at least interested in). Think of it this way: everything in the game - every element of the simulation, every resource, every script, every input device, every camera - is an "entity," which is nothing more than a unique identifier. It has some way of being associated with "components," which are the data that cause those entities to mean something. MMORPGs typically serialize the entire game state by writing this all into a relational database (give or take lots and lots of optimizations). And all of the game logic that acts on that data is handled by "systems," which might have some state of their own but mainly just get only the components they specifically need, and perform logic with them. Even the renderer is just a system, acting on entities which have components representing visual data. Usually each system does its thing once per frame, but you can put them on separate threads and get parallelism very easily. This kind of structure scales up wonderfully, but its weaknesses are the complexity and overhead of the supporting structure, and the fact that there's no more elegant way to handle interdependencies between systems than having them pass messages around. A lot has been written about the entity component system pattern, and it's interesting stuff. There are many different ways to handle the details of your game's architecture, but the relative advantages and disadvantages of any given approach aren't particularly compelling. In a hobby project involving one programmer and generous performance requirements, the best structure is the one that the programmer understands. This understanding comes from knowing what decisions you've made and why. Procedural content generation is an entirely different thing, but you might find "Wang tiles" a good phrase to start with.
|
|
#
?
Apr 19, 2013 03:44
|
|
|
Abalieno posted:I just want to know how these things are done usually, since what you see there is just what I could figure out on my own. This is just how programming works. If you're doing something repetitive you need to identify the common elements and abstract them out into a generic function or class. All your menus involve loops? Good then your general "menu" function will need a loop. You have a list of options? Well represent those options somehow (a class or struct) and put them in a list of some sort, and pass that to your generic menu function. At some point you're going to have to do something different depending on the user's selection. Maybe do that with function pointers or just have the function return the result and switch on that. I'm not saying these are the best or even good solutions but this is the sort of thing you need to think about.
|
|
#
?
Apr 19, 2013 03:45
|
|
|
Abalieno posted:The next big hurdle is to figure out how to generate an interesting dungeon instead of just rooms and corridors that look all the same. Sadly I can't find any decent guide on advanced dungeon generation. I think this depends on the type of game you want to make. What types of rooms are you thinking of making?
|
|
#
?
Apr 19, 2013 03:54
|
|
|
OtspIII posted:I think this depends on the type of game you want to make. What types of rooms are you thinking of making? Whatever makes things more interesting and varied. Right now I have these two:   And that's basically a map that only records where a cell is walkable or not. I simply want to start developing things so that these dungeons are interesting to explore, instead of being always all the same. Whatever the mean, I simply needs examples how this is done, so that I can then adapt the ideas. The best progress I had was about adding doors: 
|
|
#
?
Apr 19, 2013 07:01
|
|
|
Have you read through RogueBasin much? There's some really helpful articles here: http://roguebasin.roguelikedevelopment.org/index.php?title=Category:Maps
|
|
#
?
Apr 19, 2013 14:53
|
|
|
Abalieno posted:And that's basically a map that only records where a cell is walkable or not. I simply want to start developing things so that these dungeons are interesting to explore, instead of being always all the same. There are several simple tricks to make it more interesting though, eg. you can just add features to your existing level generation. Run a river through the cave layout, put a lake in it, an old campsite [with skeletons]. Put altars/shops/barracks/nests/fountains/pools in the room layout. Just put colors on the walls and throw out a description of some tapestries or something when the player enters the room. Change the colors of a whole level and say it's made of basalt/cheese/bones. Fill a corridor with webs that slow you down. I don't really think there's any way to make the map shape be consistently interesting. A cave is interesting after rooms, rooms are interesting after caves, but after you've had both a few times then neither is interesting. If you made some other form, it too would be interesting a few times and then not any more.
|
|
#
?
Apr 19, 2013 15:46
|
|
|
The only procedurally generated game that was interesting for me to explore was Toejam and Earl. Because it was the first I played and I was too young to understand what was going on.
|
|
#
?
Apr 19, 2013 15:55
|
|
|
Orzo posted:The only procedurally generated game that was interesting for me to explore was Toejam and Earl. Because it was the first I played and I was too young to understand what was going on. That's unfair though. Play something like Cataclysm: Dark Days Ahead. It just puts you in a randomly generated world and you have to survive. There's complete cities and houses and labs and forests and special stuff all generated, and it feels like a pretty real world. Plus it's not even near completion.
|
|
#
?
Apr 19, 2013 15:59
|
|
|
Jewel posted:That's unfair though. Play something like Cataclysm: Dark Days Ahead. It just puts you in a randomly generated world and you have to survive. There's complete cities and houses and labs and forests and special stuff all generated, and it feels like a pretty real world. Plus it's not even near completion. Procedurally generated content just isn't terribly interesting to explore, ever. How much that bothers you will depend on your love for systems over exploration, but after I've played a few games of NetHack/ADOM/etc, I get tired of it. The content is homogeneous. The typical thinking by developers is that you don't have time to make a fully realized world, so you'll make it procedurally! That way, you can have a giant world, but in much less time! ... which is a gigantic mistake. Good procedural content takes MORE effort than hand-built, not less, but very few approach it from that angle - meaning that 99.9% of procedural games are uninteresting maze slogs through generic worlds. I say this as someone with 1.5 procedural games under my belt (I was an idiot / I made that mistake). Shalinor fucked around with this message at 16:05 on Apr 19, 2013 |
|
#
?
Apr 19, 2013 16:02
|
|
|
Shalinor posted:Procedurally generated content just isn't terribly interesting to explore, ever. How much that bothers you will depend on your love for roguelikes, but after I've played a few games of NetHack/ADOM/etc, I get tired of it. The content is homogenous. Agreed. While I'm sure it's possible to have great, interesting, procedurally generated content, it seems about as far out of reach to me as great, interesting, procedurally generated music.
|
|
#
?
Apr 19, 2013 16:05
|
|
|
Jewel posted:That's unfair though. Play something like Cataclysm: Dark Days Ahead. It just puts you in a randomly generated world and you have to survive. There's complete cities and houses and labs and forests and special stuff all generated, and it feels like a pretty real world. Plus it's not even near completion. Where is the threshold at which a thing is really procedurally generated? You could for example make a "town" level where there's 5 or 6 rectangular/square houses, arranged in a slightly askew grid, and sure it's procedurally generated but it's your design that says there's 5 or 6 of them and that they'll be approximately in a grid. What I'm getting at here is that it's a lot easier to make interesting levels if you make your procedural generation run as components, because then you can describe a level to your engine ("six houses, a river from the south running to a lake in the north, and a fire pit in the northeast quadrant") rather than just running a single algorithm per level ("make caves", "make rooms", Nethack style.) Even if you end up also randomly generating your "description" step, it'll still produce less repetitive output than a flat function ever could.
|
|
#
?
Apr 19, 2013 16:21
|
|
|
Jewel posted:That's unfair though. Play something like Cataclysm: Dark Days Ahead. It just puts you in a randomly generated world and you have to survive. There's complete cities and houses and labs and forests and special stuff all generated, and it feels like a pretty real world. Plus it's not even near completion.
|
|
#
?
Apr 19, 2013 16:49
|
|
|
I'd echo the suggestions for RogueBasin, and you might take a look at Brogue. It's open source so you can step through everything that's going on, including with a debugging mode turned on that highlights the various steps of level generation. Also I think there was a decent bit of goon interest + accolades for it when it came out a few years back!
|
|
#
?
Apr 19, 2013 17:37
|
|
|
Shalinor posted:So did ADOM, and that's one of the best out there. It was still dull to explore. The way I see it, exploration really needs exploration-based meaningful choices to be interesting, and I'm not sure I can really think of any procedurally generated games that especially work to encourage those. I should probably elaborate on what I mean by 'meaningful choices'. In this context I think it's mostly about prediction--can you use what you can currently see in the game world to be able to seek out things you want to find and evade things you want to avoid? That's not really a thing most of the time in a roguelike--generally there isn't any thematic interaction between neighboring rooms beyond maybe a general level-wide theme. For exploration to be fun you really need to generate situations like "dozens of human bones are scattered in front of the great bronze doors--do you risk the level-inappropriate danger in hopes of finding level-inappropriate treasure or do you play it safe?" Also, when things like this do come up they tend to lose their prediction-based-fun pretty quickly because they become TOO predictable. If a bone-lined brass door always means there's a balor behind it there's hardly any exploration to be done there, either. You find the door randomly, and the moment you look at it you already know what's behind it, so it's really just like finding any other room. If scattered skulls mean undead 50% of the time, nothing unusual 30% of the time, a balor 15% of the time, and an unguarded item of great power 5% of the time then you actually have a chance to explore--a moment where you can enter an area, look for clues, and then decide at any moment if the clues point towards a situation you just won't be able to deal with. This is all fairly tricky, of course, which is why we don't see it a lot. I don't think it's impossible, though.
|
|
#
?
Apr 19, 2013 17:43
|
|
|
Eh, I mean even exploration-based games like Skyrim and Oblivion are built largely procedurally, then hand-tuned. I think procedural world-building is one of those things that suffers from a bit of confirmation bias; when you see terrible procedural work, you're like "wow procedural generation sucks"; but when it's good, you don't notice it. We're still not at the point where you can just throw down a 100% procedural world and have it be particularly compelling, you still need to mix in some human creativity. For now. I think some of you that are shooing procedural game generation are basing it on previous generation's games, and you'd find it getting better and better. e: Like RoomForTuna said, with Caves of Qud, we basically turned the procedurally-generate than hand-tune of Elder Scrolls on it's head. We essentailly designed a lot of content that may or may not appear in the world, as well as the way that content related to things that are generated procedurally; so that certain things are constant every time you start, and certain things are highly variant. It's sort of as if with each game of Morrowind; you always had a vivic, and you always had a starting town, and always had a few of the key story dungeons, but the rest of the game used pieces grabbed out of a big grab bag of hand-built and procedural content. So you get a largely new game-flow each time you run through, even though the overall arc remains. Unormal fucked around with this message at 21:45 on Apr 19, 2013 |
|
#
?
Apr 19, 2013 21:38
|
|
|
I think procedural works well as long as: 1) the actual gameplay is fun as hell and 2) the player doesn't "see the Matrix" easily and figure out how it's all being put together The idea of a completely random 3D world for Hellgate: London was a really cool one and the environments technically looked nice but the resulting layouts were just so goddamn boring. It literally didn't matter what shape the enrionemtn was because it didn't change the gameplay one goddamn bit. A game like Spelunky on the other hand revels in randomly generated maps and I couldn't see it working any other way.
|
|
#
?
Apr 19, 2013 23:37
|
|
|
Unormal posted:e: Like RoomForTuna said, with Caves of Qud, we basically turned the procedurally-generate than hand-tune of Elder Scrolls on it's head. We essentailly designed a lot of content that may or may not appear in the world, as well as the way that content related to things that are generated procedurally; so that certain things are constant every time you start, and certain things are highly variant. It's sort of as if with each game of Morrowind; you always had a vivic, and you always had a starting town, and always had a few of the key story dungeons, but the rest of the game used pieces grabbed out of a big grab bag of hand-built and procedural content. So you get a largely new game-flow each time you run through, even though the overall arc remains. Basically, procedural generation should be a tool in your toolkit for level design, but it shouldn't be the only one, or even the primary one. Even Zelda had a procedural section (the Lost Woods), but nobody is going to call the game procedural because of it.
|
|
#
?
Apr 19, 2013 23:42
|
|
|
Shalinor posted:Right, but that isn't a game you'd advertise as "procedurally generated! unlimited content!" - that's just a mostly static, well-designed game. I don't think anyone would argue that advertising Nethack as procedurally generated wouldn't be right. Edit: also, Nethack too is a lot more interesting for this fact. Back in the day it didn't have these special levels and it wasn't that great. Also I'm not sure if the Sokoban tower is in Nethack or just in SLASH.
|
|
#
?
Apr 19, 2013 23:51
|
|
|
Procedurally generated content can be effective if that content is being consumed by a system which necessarily responds differently to differences in the content, but always works no matter what content is generated. That's a very difficult balance to strike, because it requires game mechanics that establish a dense and detailed possibility space without themselves being dense and detailed. It can also work for generating content that makes no difference at all but which nevertheless needs to exist in vast quantities. Level layouts aren't an example of this kind of content, though.
|
|
#
?
Apr 20, 2013 00:20
|
|
|
roomforthetuna posted:Can you give an example of something in which dungeons are interesting to explore? Because that's a really vague goal at the moment, it's not a programming or algorithmic question at all, it's a "what do people like?" question, and I honestly can't even think of a single game that has randomly generated levels that are interesting to explore. At best, there's randomly generated levels that are the chore to explore in between hand-designed levels that are interesting. You guys don't understand what I'm asking. I'm not asking for ideas on how to make interesting dungeons, I'm asking on programming advices on how to implement more complex (generated) spaces REGARDLESS OF SETTING. I want to know how poo poo is done usually. Once I know, I can do it myself my own way. So if someone took a random game that generates somewhat more interesting dungeons that don't simply have rectangular spaces and nothing else, and then explained me step by step how those things are built, then it would be exactly what I'm looking for. It doesn't even need to be C++ specifically. quote:There are several simple tricks to make it more interesting though, eg. you can just add features to your existing level generation. Run a river through the cave layout, put a lake in it, an old campsite [with skeletons]. Put altars/shops/barracks/nests/fountains/pools in the room layout. Just put colors on the walls and throw out a description of some tapestries or something when the player enters the room. Change the colors of a whole level and say it's made of basalt/cheese/bones. Fill a corridor with webs that slow you down. Yes, these are some ideas. But I have ideas. I want processes that I can analyze. "Run a cave through the cave layout" is useless to me. What could be useful is some article explaining a procedure that runs the river through the cave. I want implementation details, not vague ideas. Take even Cataclysm. I know what it has. I see the roads and the different houses, shops and so on. All this is the useless part. I want to know how all this stuff is put together (and don't tell me to look at the code, because I don't know the language remotely enough to be able to read someone else's code). Or even Brogue. Is there an in depth guide that explains how the dungeon levels are built? Is there a guide that explains how to generate dungeons that aren't simply made by rectangular rooms and nothing else? Is there something that covers slightly more advanced stuff? Abalieno fucked around with this message at 00:28 on Apr 20, 2013 |
|
#
?
Apr 20, 2013 00:22
|
|
|
Procedural World is a blog about one person's ongoing efforts to address this sort of problem. It's incredibly impressive, but for the specific context of dungeon generation, these two posts and their comments will definitely be a good starting point. The short version is: you start with a bunch of prefabricated rectangular sections, "color"-coded according to their exits, then lay them out randomly so that they match. That's "Wang tiles" and they're a pretty basic concept. To make the patterns in them more interesting and harder to discern, you can make the tiles a different shape and lay them out in a more interesting pattern than just a rectangular grid; in the second post, the author links to a paper describing using Wang tiles in a herringbone pattern. Of course, this leaves you with the problem of needing content with which to fill in the tiles. This is now a smaller problem than generating entire dungeons. All sorts of tools, from hundreds of hand-designed tiles to techniques like Perlin noise and genetic algorithms and even machine learning, can be applied to this end, but you're not going to make much progress without intimately understanding your own specific needs and the consequences of each approach. In terms of programming, however, probably it would be best to write a separate program to export all of your tiles to files or a database, which you then ship with the game and read at runtime when you run your tiling algorithm. This may be overkill if you're just trying to make a plain old roguelike. If you want to see how other roguelikes have done it, many approaches are documented in the articles on Roguebasin. Run a search for "generation" and see what comes up. Bongo Bill fucked around with this message at 00:37 on Apr 20, 2013 |
|
#
?
Apr 20, 2013 00:35
|
|
|
There's lots of articles on this huge subject, and almost as many different methods as there are roguelikes out there. http://roguebasin.roguelikedevelopment.org/index.php?title=Articles#Map is the tip of the google search iceberg.
|
|
#
?
Apr 20, 2013 01:30
|
|
|
http://www.amazon.com/Texturing-Modeling-Third-Edition-Procedural/dp/1558608486 This book is a pretty great foundation on procedural 'stuff'. It's title is a bit misleading, as it ends up just being a treatise on procedural world generation. (Which isn't that crazy, if you imagine a level in a roguelike as no more, really, than a complicated, well-structured texture.) e: To continue the sort of philosophical procedural-game talk; I think the sort of gameplay that benefits from a "procedural" vs "hand built" world tends towards different categories of game. In it's best forms, procedural games provide gameplay that is very open-ended, promoting emergent, creative solutions; whereas hand-built games like metroid are great in their own right, but they focus on a much more exacting puzzle-solving, and less of an open-ended interaction with the game (except when you're openendedly traversing every goddamn dead-end trying to figure out what you missed). Roguelikes in their best form provide a series of tactical challenges that can be solved in a huge number of ways, sometimes in very unique and emergent ways that would be difficult or impossible to reproduce in a hand-build game world. In much the same way that it's very difficult to reproduce the gradual unfolding/discovery/re-exploration of a metroid/metroidvania game in a procedural game. Procedural levels aren't just "levels you use when you don't have time to design them."; Look at FTL for a great example of a game that would gain no benefit, and would be much worse, without procedurally generated content each play. In fact look at some of the most basic games, like most card games. Your hand and play environment is generated "procedurally" each time, and a card game where you got the same series of cards each time might have upsides, but certainly wouldn't be "better" in any significant way than Poker. Unormal fucked around with this message at 01:53 on Apr 20, 2013 |
|
#
?
Apr 20, 2013 01:41
|
|
|
Abalieno posted:So if someone took a random game that generates somewhat more interesting dungeons that don't simply have rectangular spaces and nothing else, and then explained me step by step how those things are built, then it would be exactly what I'm looking for. It doesn't even need to be C++ specifically. I think this is the third or fourth time I've brought it up recently, but the random terrain generation for SimCity was both absurdly simple and perfectly effective and you might find it useful. When it puts a river into the map, it picks a random x,y coordinate and stamps a 2D array of river around that point. Then it shifts the x,y randomly, and stamps it again. It continues this until it hits the edge of the map. This type of thinking may be useful to you.. if you wanted to carve out a sequence of caves you could rip this method off directly. If you wanted to make a room shape irregular, you could write a function to traverse the borders of the room and randomly stamp chunks out of the walls. There's a java implementation of the original SimCity algorithm here if you want to peruse the code: https://code.google.com/p/micropolis/source/browse/trunk/micropolis-java/src/micropolisj/engine/MapGenerator.java Pay special attention to the doBRiv and BRivPlop methods. Lakes and rivers use a similar method. For making interesting sequences of hallways, you should look into l-systems. They're also really easy to implement, and are pretty much what everyone uses when procedurally generating city streets. It should be pretty easy to apply the logic to making dungeons.
|
|
#
?
Apr 20, 2013 01:58
|
|
|
http://en.wikipedia.org/wiki/Wang_tile is another really simple but incredibly effective means of generating procedural stuff that is widely used with good results, plus it's called wang. e: Beaten like a horse. Nonetheless, some combination of wang tiles and perlin noise will take you pretty long way. Wang tiles are good at 'man made' looking stuff, and perlin noise is very good at emulating natural phenomena. Unormal fucked around with this message at 02:24 on Apr 20, 2013 |
|
#
?
Apr 20, 2013 02:20
|
|
|
roomforthetuna posted:That's a factor too - Caves of Qud has more interesting levels, but mostly I feel that's because they are barely randomly generated. You start in a hand-made town, you go through four randomly generated 'outdoor' scenes which are a bit bland, then you get a "randomly generated" cave, which consists of a couple of floors of Nethack, then a river and lake is added in which is "randomized", but the fact that it's there is a hand-designed thing. You can follow the river south to more rooms, which again goes through a series of randomly generated "river cave" rooms, but the fact that they are river-cave rooms, and the method of random generation of such rooms, is hand-designed. This is how Path of Exile works by the way. There is actually an interesting video on youtube where they describe their editors. They basically build a graph describing a rough level, building, whatever, and their procedural gen uses that to construct something that meets all the criteria yet is unique every play through.
|
|
#
?
Apr 20, 2013 02:42
|
|
|
Abalieno posted:You guys don't understand what I'm asking. I'm not asking for ideas on how to make interesting dungeons, I'm asking on programming advices on how to implement more complex (generated) spaces REGARDLESS OF SETTING. You can download Brogue's source, set DEBUGGING, D_INSPECT_LEVELGEN, and D_INSPECT_MACHINES all to 1 (in the Rogue.h file), and then compile + run it. Now whenever the game generates a new level, it will tell you exactly what's going on. It will create a room and attempt to place it somewhere sensible in the level, then probably add some lakes/chasms/swamps/lava, go through feature generation (grass/fungus/forest/etc), clean up edges, place staircases, and spread items all around. If you're looking for how it works at a lower level than what the debugging and extra level generation information gets you (e.g. how it creates a candidate room in the first place, in the designEntranceRoom and/or designRandomRoom functions), you can trawl through the codebase in Architect.c; level generation begins with, obviously enough, the startLevel function. And Brogue is also nearly entirely done in C and not anything super obscure! Anyway I'll shut up about Brogue. Hopefully this has been at least a bit useful!
|
|
#
?
Apr 20, 2013 04:31
|
|
|
Unormal posted:http://en.wikipedia.org/wiki/Wang_tile is another really simple but incredibly effective means of generating procedural stuff that is widely used with good results, plus it's called wang. Really, if you're making a procedural game, you'll end up with a ton of these. Different algorithms are how you theme different areas. BSP-based dungeon generation is great for your cave sections, Wang is great for gridded environments (say, a prison/dungeon), Herringbone is good for similar patterned but slightly less regular environments (maybe man-made caverns or a a building interior), weather wearing systems are used for external environments, etc. EDIT: Oh, never mind, Procedural World has a link to that too. Dang.
|
|
#
?
Apr 20, 2013 05:38
|
|
|
Abalieno posted:You guys don't understand what I'm asking. I'm not asking for ideas on how to make interesting dungeons, I'm asking on programming advices on how to implement more complex (generated) spaces REGARDLESS OF SETTING. This is a really really big question, which is why I think you're not getting the answers you want. The techniques you should be using to make a roguelike where you're just supposed to run straight down until you hit the bottom are very different than the techniques you should be using to make a roguelike where you move between dungeons and are expected to defeat each one over the course of multiple delves are very different from the techniques you should be using to procedurally design towns, and so on. It all depends on, like, how interested you are in controlling mobility within your created space/creating 'natural'-feeling setups/giving people ways to avoid interacting with too-dangerous content/controlling encounter placements/etc. I've been meaning to put together a nice big write-up of what I'm trying to do, anyway, so I guess I'll type something up for Screenshot Saturday. I'm not sure we're trying to make especially similar things, but it's always handy to see how other peoples' thought processes work.
|
|
#
?
Apr 20, 2013 05:44
|
|
|
roomforthetuna posted:That's a factor too - Caves of Qud has more interesting levels, but mostly I feel that's because they are barely randomly generated. You start in a hand-made town, you go through four randomly generated 'outdoor' scenes which are a bit bland, then you get a "randomly generated" cave, which consists of a couple of floors of Nethack, then a river and lake is added in which is "randomized", but the fact that it's there is a hand-designed thing. You can follow the river south to more rooms, which again goes through a series of randomly generated "river cave" rooms, but the fact that they are river-cave rooms, and the method of random generation of such rooms, is hand-designed.
|
|
#
?
Apr 20, 2013 05:45
|
|
|
Abalieno posted:I've got to figure out how to make some UI without losing sanity on it. Consider I know very little about programming and doing this in C++ using the libtcod library. I don't know what programming language that is, but I'd only make minor changes to this: code:Mug fucked around with this message at 13:53 on Apr 20, 2013 |
|
#
?
Apr 20, 2013 13:47
|
|
|
That Turkey Story posted:Agreed. While I'm sure it's possible to have great, interesting, procedurally generated content, it seems about as far out of reach to me as great, interesting, procedurally generated music. Although I'd argue there's plenty of great, interesting, procedurally generated music, it's an extremely hard thing to do and games, like music, are best served incorporating such processes into the overall fabric rather than it being completely central to the experience
|
|
#
?
Apr 20, 2013 16:42
|
|
|
Anybody have any experience coding multiplayer games in Unity? Any thoughts on the best way of handling an authoritative server when you need to possibly calculate physics and collisions server side? Just looking for some advice from anybody who's tackled this previously. I've had no problems implementing Lidgren within my Unity client but currently I'm just using a simple windows form application with Lidgren as the server. I'm thinking it might be easier in the long run to just implement my server as a seperate Unity application. I've read that the standard multiplayer framework within Unity is less than ideal but I don't know how much truth there is to that.
|
|
#
?
Apr 20, 2013 18:36
|
|
|
Alright, all this convinced me to actually write up a big post about what I'm trying to accomplish with my roguelike and how I'm trying to do it. I'm really interested in figuring out how to make procedural generation less bland, and am really fascinated with the whole concept of meaningful choices in games, so a lot of this is me wanting to put my ideas to the test. If any of this looks non-viable to any of you I'd love to be called out. Here's a basic map of what a level in it looks like (sorry if it's a bit hard to read in places, it's a diagnostic map):  As I go over what I'm trying to design a level-generator to do, you'll notice a lot of what I'm talking about isn't completely working in this example map. I'm still adjusting a lot of my systems to try to make sure that they usually produce good results without being checklist-predictable. Also, these maps I'm making currently are very small, so I'm hoping once the map's a bit more dense some of my current problems will naturally lessen. Okay, so I'm trying to make a procedural game that actually makes exploration fun. What concepts do I need to consider to make that work? Why Procedural At All? The conversation recently in this thread in general makes a pretty good point for why procedural generation might just not be good at creating interesting game-settings, so why am I even going procedural at all with this? Part of the reason is because I'm really interested in putting the basic question of 'what makes for fun exploration' under stress by trying to reduce it to a bunch of relatively simplistic equations (something I already know is impossible), but I think there are a few good reasons beyond that. I think the biggest enemy of exploration is knowing what's ahead of you. A huge part of the fun of exploration is seeing a hill and trying to imagine what might be behind it--trying to make predictions, but also hoping that maybe it'll be something brand new you've never seen before. Going over the hill to find a city behind it is really exciting (doubly so, because just as your first question of 'what's behind the hill?' gets answered you get given a new one of 'what is this city like?'), but it's a sensation you can only get once per hill. In a non-procedural game you'll always know what's beyond the hill on repeat playthroughs, so you pretty much 100% lose exploration as a source of fun after your first playthrough. Procedural generation is fun because it allows for much greater replayability. Also, hand-made content is pretty much always made to be seen; there isn't too much point in making content that you're expecting the player to skip. The problem with this, though, is that if the player is expected to visit all the areas in a game you lose out on a bunch of the predictive side of exploration-fun. Players should be rewarded for trying to predict what's beyond the hill, and one of the biggest ways to reward prediction is to allow the player to skip challenges with an undesirable cost/reward balance. A procedural world means that you can make tons of content that the players can choose to skip without feeling like they're not getting everything they paid for in buying the game, and the existance of that content actually gives players meaningful control over where they go in the game-world; the choice goes from being 'do I want to go here now or later' to a more meaningful 'do I want to go here at all' (linear worlds don't offer any choice at all). Also, and I'll just skim over this for now, multiple world-populating subsystems allow for all sorts of new content not ever imagined by the game designers. Control of Space I think this is one of my biggest issues I'm struggling with in level-design--there needs to be a balance between restricting player movement and allowing for the player to choose their own path. Knowlege and control of the map are rewards in an exploration-based game every bit as much as XP and treasure, and so you really do need things like shortcuts, roadblocks, loops, and so on as part of your map design process. I try to handle this in my game by putting everything on a 'GeoGrid'. I break my map into lots of 18x18 square tiles and have the game draw a linear/branching path through it, then go through each tile and give it a chance to create secondary connections with other tiles neighboring it. I end up with something kind of like this:  This is where things start to break down. You can see where I get a nice loop in the bottom center, but it's small enough that I really can't call it a shortcut or anything.  Something like this would be way more sexy. Figuring out how to make this happen more a more desirable frequency is one of the big issues I'll be working on coming up. It wouldn't be good if everything was a loop--having choke-points is really important, but I want linear zones, not linear levels. Once I have this layout-map I use my psuedo-Wang tiles (inspired by D&D Geomorphs) to build a skeleton of the map the players will actually walk around on. This is pretty much just made up of hallways, although it includes some rooms in patterns that are too interesting to be likely to pop up through totally random chance, and also some big setpieces locations that are a full 18x18 squares (or larger) in size. They're all pre-drawn by me, but can be rotated and flipped and so on to make them a bit harder to read. Also, They can take up more than one slot on the GeoGrid, letting me give the appearance of going off the grid with my connection-placements.  The blue sections are what's been placed at this stage. Note how most of the halls connect to each other in the center of the GeoGrid tile, but in some places they connect on the sides/etc--that's due to the prefabbed Geomorph being two tiles wide, letting me place stuf wherever I drat want within it. Once this is placed I start budding pre-drawn rooms off of the sides of it until I have a proper number of rooms/run out of space--these are all the white segments of the above map. The part of the map they're in chooses a desired type of room (Coffin-Filled Room), which then picks a pre-drawn room-shape out of a list of possibilities (Rectangle) and then buds it off of an empty slot of wall. This lets me have a relatively repetitive but reliably connectable skeleton to my map without having it look stale and repetitive to the players. It also lets me break free of the 18x18 square grid a bit, keeping me from having a no-content crease every 18 squares between tiles. I also use this as a chance to try to make a few more loops. Each room has a door that it buds from, but if it borders other rooms there's a chance it'll spawn an additional door to them. You can see this with, for example, rooms 51 and 50, where they creat a little mini-loop. They can even connect between far-apart sections of map. . .but that didn't really happen this time. I'd love it if rooms 55 and 63 connected to each other. I have a few things in place to encourage that to happen, but obviously it still needs work. Christ, this is turning into a big post. I'll end this post for now, I guess--this is just the very basics, and honestly the layout of the map is one of the least important parts of making exploration meaningful. I'll get to keywords and room-contents later. Let me know if anybody wants any further explanation of a part or if I'm being unclear or something.
|
|
#
?
Apr 20, 2013 21:41
|
|
|
OtspIII posted:Awesome stuff Great post, looking forward to the continuation. In some of my more experimental work with Caves of Qud, that hasn't really made production yet, I make use of "property" spreading maze-generators, and overlayed "property" influence/noise maps. One of the things that I think queues the human exploration pleasure buttons is following some sort of logical trail/gradient to find something cool. That is, you might be in a forest and notice some pavers or crumbled stone, which you can follow off into the woods, gradually getting denser until you find a cool tower. In order to simulate these, I've been experimenting with generating features based on property maps like "ruiny", "crystaly", "techy", "androidy", and looking at local maxima of those maps to place rare or unique special builders. I've been toying around with combining simple perlin-based noise for those properties with maze-builder based tapering trails of those properties, so that you can walk through a forest, and run across some scattered ruins, and poke around and sometimes be able to eek out a trail of ruins towards a local maxima where you find a dungeon. This helps break up the blandness of purely noise-based geography, and helps queue the "tracking" portions of your brain, which seem to be instinctively fun to utilize.
|
|
#
?
Apr 20, 2013 22:31
|
|
|
|
| # ? May 25, 2024 16:46 |
|
|
Unormal posted:In some of my more experimental work with Caves of Qud, that hasn't really made production yet, I make use of "property" spreading maze-generators, and overlayed "property" influence/noise maps. One of the things that I think queues the human exploration pleasure buttons is following some sort of logical trail/gradient to find something cool. That is, you might be in a forest and notice some pavers or crumbled stone, which you can follow off into the woods, gradually getting denser until you find a cool tower. In order to simulate these, I've been experimenting with generating features based on property maps like "ruiny", "crystaly", "techy", "androidy", and looking at local maxima of those maps to place rare or unique special builders. I've been toying around with combining simple perlin-based noise for those properties with maze-builder based tapering trails of those properties, so that you can walk through a forest, and run across some scattered ruins, and poke around and sometimes be able to eek out a trail of ruins towards a local maxima where you find a dungeon. This helps break up the blandness of purely noise-based geography, and helps queue the "tracking" portions of your brain, which seem to be instinctively fun to utilize. Ooh, I do something a little like this, but this sounds a lot better for placing hints at a distance from the tower or whatever. How many properties would you be using? I'm going to have quite a few, so having a map for every single property isn't really practical for me. What would an area with a "ruiny" rating of 12, a "crystaly" rating of 60, a "techy" rating of 49, and a "androidy" rating of 81 look like? I do a few things, but for placing hints about nearby features I just make it so that some monsters/rooms/etc place a property mark on the area around them in a radius, so even if I have a hundred properties in the game the random content generator only has to worry about maybe 5 or so when populating any one room. I actually have almost no hard links between objects in the game, using pretty much only properties to decide what goes where, and it makes things spiral into nonsense really easily, so take everything I say with a grain of salt. I feel a little bad making this big post about procedural generation in this thread when there are so many people in it with so much more experience at it than me, so please read all of this more as me trying to organize my own understanding of all this to myself than as me trying to convince anybody of anything.
|
|
#
?
Apr 20, 2013 23:15
|
|