|
One thing that I know UDK had trouble with was spawning particles on the surface of a Mesh without a lot of hacky coding. Surprisingly also they show in the documentation "HEY YOU CAN USE RAYTRACING TO, SAY, PROJECT A DECAL ONTO THE ENVIRONMENT", and show a picture of it, and I've never actually found documentation or any resources on the entire internet on how to accomplish that (the only thing I can do is find a game that's done it and look at their code). Hopefully UDK4 provides a lot more of these nice things (it seems they will, with the huge new Kismet and particle stuff, plus they showed the water ball putting wet decals on the ground). Edit: Quoting this for the new page: Jewel posted:Holy poo poo holy poo poo holy poo poo.
|
#
?
Jun 8, 2012 17:26
|
|
|
|
| # ? May 27, 2024 06:16 |
|
|
Shalinor posted:Most of which being because they went to a fully deferred rendering scheme! Which is totally freaking cool. I'd bet on some variation of screen-door for out of the box, since that's the most salable and general purpose, if not necessarily the most attractive. It's a good question though, if they're 100% deferred.
|
|
#
?
Jun 8, 2012 17:36
|
|
|
I'm kind of unimpressed since a lot of that is old news, or trivial at this point. Environmental specular means they're probably using light reinjection, but light reinjection has been a yawner ever since better culling techniques like tiled deferred were introduced. GPU particles are a solution in search of a problem unless they do a lot more than what they've demoed. Instant play in the editor is something I can barely commend them for because it's really loving overdue. Like, by 10 years or so. Blueprint's probably the most impressive thing in the video, really, and they didn't go into it that much. Really, the workflow changes are what's going to make or break this given their current competition, and that much looks a hell of a lot better than UE3 at this point. OneEightHundred fucked around with this message at 17:54 on Jun 8, 2012 |
|
#
?
Jun 8, 2012 17:48
|
|
|
Unormal posted:I'd bet on some variation of screen-door for out of the box, since that's the most salable and general purpose, if not necessarily the most attractive. It's a good question though, if they're 100% deferred. I mean, it does work, and it does solve the problem, but... eeeewww. Still, yeah, it's the easiest way of handling it. That aside, yeah, nothing here is that tremendously surprising. I have a huge love of deferred rendering, but it's old tech. I wrote a deferred renderer back in 2005, and it wasn't even that new back then. Similarly, their particles are really just, well, particles, but now GPU accelerated. I just view it as further evidence that we're reaching the end of the era of computer graphics defining the leaps forward in gaming. This is Unreal, "the" engine group, and all they've really done is added more of everything. More polygons, more particles. Cool, but it's just an evolutionary advancement, nothing really revolutionary. They didn't show much with caustics, either. I was expecting some kind of warpy glassy structure, lensing, etc. I wonder if it's because that plays havoc with their real-time light bouncing, hehe. Most troubling, and why I'm not personally interested, is that they didn't show a hint of how we should expect to be able to do any of this high fidelity stuff without a fleet of artists. I mean great, those particle systems are awesome... but how much work went into just one of those magical woo-woo traily things? That environment is awesome, incredible even, but how much extra work is it going to take to get the lighting in a scene to match your visual target if you've got to worry about bounced color now? And of course the usual "great, now we have to model everything in even higher detail" arguments, etc. I'd really like to see some attention paid to cutting art costs, instead of just increasing the complexity of art required to match expectations. Shalinor fucked around with this message at 17:57 on Jun 8, 2012 |
|
#
?
Jun 8, 2012 17:53
|
|
|
Shalinor posted:I'd really like to see some attention paid to cutting art costs, instead of just increasing the complexity of art required to match expectations. Yeah, I mean other than cross-platform mobile, one of the huge selling points of Unity for me is the still nascent, but really compelling story of the asset store, where I can go for code snippets/art/etc in a streamlined, integrated way. That's a really understated, but important, thing that unity does really well to reduce development and content creation effort and cost.
|
|
#
?
Jun 8, 2012 18:00
|
|
|
How are they doing the C++ edit / compile without reload? I imagine you can't do that with the base engine, so it must only be supported with the game dll. So I guess it must go something like: 1. compile new game dll 2. when finished pause and save game state 3. unload old dll, load new dll 4. restore game state, unpause Except he was moving the entire time without any noticeable hiccup or anything. EDIT: Actually there was a noticeable hiccup when looking at it a second time. I imagine if you aren't running on a beastly machine its even more noticeable. xgalaxy fucked around with this message at 18:31 on Jun 8, 2012 |
|
#
?
Jun 8, 2012 18:02
|
|
|
xgalaxy posted:Except he was moving the entire time without any noticeable hiccup or anything. Shalinor posted:I view it as further evidence that we're reaching the end of the era of computer graphics defining the leaps forward in gaming. This is Unreal, "the" engine group, and all they've really done is added more of everything. More polygons, more particles. Cool, but it's just an evolutionary advancement, nothing really revolutionary. That said, the landscape of graphics as a defining factor has been changing for other reasons. i.e. one big shift happening right now is the improved integration with tools. A lot of demos these days have been significant because they've been blatantly been set up in Maya rather than engine tools. Demos used to be playarounds in some physics or graphics demo room, not animated shorts. I guess the most succinct version of it is that games are shifting toward fulfilling an artistic vision rather than a technological one, and that's been happening for a while. God of War 3's tech is comical, it supports one light PER VERTEX, yet its visuals were extremely praised. The only tech that matters these days is tech that facilitates the art. The only shift I can see away from this is a greater focus on world interactivity, which I couldn't complain about, but that's not something predicated on an amazing renderer either. Workflow, scale, and interactivity are probably the most important things in any engine right now.
|
|
#
?
Jun 8, 2012 19:12
|
|
|
It's not so much that rendering has reached a point where further improvements provide little additional value, so much as that rendering has gotten so complex that content creation takes much more time and so tools and content production are the largest limiting factors, not technical constraints. In that sense OneEightHundred is exactly right It's true that you see a much larger variety of target styles and aesthetics, and that the proportion of games that would really benefit from improved fidelity is smaller, but that's really as much a result of the industry and the technological horizon broadening as it is anything else. People still wanted to play Monkey Island when Doom and Quake came along, but that doesn't mean either examples couldn't (or haven't) been improved upon technologically. Shalinor posted:Similarly, their particles are really just, well, particles, but now GPU accelerated. I just view it as further evidence that we're reaching the end of the era of computer graphics defining the leaps forward in gaming. This is Unreal, "the" engine group, and all they've really done is added more of everything. More polygons, more particles. Cool, but it's just an evolutionary advancement, nothing really revolutionary. SVOGI is hugely revolutionary, and a development timesaver since it completely eliminates the need to bake massive light-maps or fiddle with tons of aphysical lights to approximate plausible illumination. GPU-accelerated particles are huge because they've got major platform implications -- less time spent updating particles on the CPU means more time for animating characters and AI/collision processing. By simply moving the workload to another processor with horsepower to spare that is well suited for it, you free up more resources for things like AI and Game logic that are starving for CPU cycles. It's primarily a technical innovation rather than something fundamentally new, but it does potentially have a lot of secondary benefits.
|
|
#
?
Jun 8, 2012 20:26
|
|
|
Before I forget, the best thing about that demo is  they don't use rim lighting, vignetting, or color grading . That's practically an innovation at this point. Fortunately, they've made up for that lack of triteness by introducing Lens Flare 2.0.Hubis posted:SVOGI is hugely revolutionary, and a development timesaver since it completely eliminates the need to bake massive light-maps or fiddle with tons of aphysical lights to approximate plausible illumination. Hubis posted:It's true that you see a much larger variety of target styles and aesthetics, and that the proportion of games that would really benefit from improved fidelity is smaller, but that's really as much a result of the industry and the technological horizon broadening as it is anything else. People still wanted to play Monkey Island when Doom and Quake came along, but that doesn't mean either examples couldn't (or haven't) been improved upon technologically. quote:GPU-accelerated particles are huge because they've got major platform implications e: Clouds and fluids are much more useful simulation problems they could have solved. OneEightHundred fucked around with this message at 22:15 on Jun 8, 2012 |
|
#
?
Jun 8, 2012 22:02
|
|
|
OneEightHundred posted:The problem is finding scenarios where you actually want a huge number of particles. The visual effects industry has been abusing particles for the past few years for the dissolving/reassembling of solid objects, that's probably where the tech is headed for real time
|
|
#
?
Jun 8, 2012 22:11
|
|
|
That's really clever how they do the recompile on the fly. That must have had engine developers hi-fiving for weeks when they figured that out.
|
|
#
?
Jun 8, 2012 22:38
|
|
|
Jewel posted:Edit: Also remember that there's no UnrealScript anymore, only C++, thank god. Really looking forward to this. Is the new UDK going to be made freely available? Do we know when? Interface looks pretty good, but I'm not sure how well my computer will handle it all.
|
|
#
?
Jun 8, 2012 22:38
|
|
|
mewse posted:The visual effects industry has been abusing particles for the past few years for the dissolving/reassembling of solid objects, that's probably where the tech is headed for real time Fluids, on the other hand, are something we flat out nearly can't do right now. If we had proper fluids, more world interactivity, that could inherently shift the sorts of in-game scenes that are possible. More particles is just... more. Granted, massive physical particle sims on the GPU may allow us to more convincingly simulate basic fluids, which would be cool. I'm also kind of disappointed by the lack of fractal asset generation tools. That area seems criminally under-exploited, and would be fertile ground for small teams making content that could rival the fidelity of what large teams produce. ... and this is coming from someone who broke into the industry as a graphics programmer. Not entirely sure when I became a boring "but why do we need more particles" person. EDIT: I think it boils down to, the last time we had a major engine cycle, I wasn't dialed into the industry at all. Now, I'm looking at this stuff going "eh, ok, 5 year old research." That was probably the case last time too, I just wasn't aware of it. I'm probably just being a wet blanket here. Shalinor fucked around with this message at 01:57 on Jun 9, 2012 |
|
#
?
Jun 9, 2012 01:51
|
|
|
Shalinor posted:Fluids, on the other hand, are something we flat out nearly can't do right now. If we had proper fluids, more world interactivity, that could inherently shift the sorts of in-game scenes that are possible. More particles is just... more. Granted, massive physical particle sims on the GPU may allow us to more convincingly simulate basic fluids, which would be cool. Fluids are particles, or at least that's how they will be implemented. In fact I'd say fluid simulation is likely to be the killer app for GPU particle systems.
|
|
#
?
Jun 9, 2012 02:24
|
|
|
In terms of content creation, you guys should check out some of the stuff one of my professors did -- here's a video of being able to generate real-time animations based on a staggeringly small amount of input data. When the video flashes a half-second clip of an animation cycle, that's the full length of the training data. It starts off with running, then non-bipedal motion, then actual physical actions. It was a  moment when I saw it the first time. This stuff is some of the coolest stuff I've seen in a long time.http://vimeo.com/41993867 There's also another project involving 'learning' components of an object and then remixing them on-the-fly to create new models. http://vimeo.com/41990868 I don't know to what extent these are solved problems, but it's all fairly recent (the animation clip was submitted to a conference for this year, I believe), but I found these videos really astonishing and mind-boggling.
|
|
#
?
Jun 9, 2012 02:38
|
|
|
This is incredibly sexy. I've seen related work before, but only in the last year or so, I think. Or maybe it was this video? Anyways, it kind of brings us back to Unity 3D. That's the kind of tool / algorithm that gets my attention for making next-gen content doable, and while Unreal isn't likely to ever go that route (since they're focused on big art teams) - it's a great thing for someone to make a plugin for, and throw it up on the Unity store. EDIT: VV OneEightHundred posted:A lot of UE4's value will come down to the improved workflow though, so I'm still waiting to hear more about that. Shalinor fucked around with this message at 03:19 on Jun 9, 2012 |
|
#
?
Jun 9, 2012 02:59
|
|
|
Shalinor posted:... and this is coming from someone who broke into the industry as a graphics programmer. Not entirely sure when I became a boring "but why do we need more particles" person. A lot of UE4's value will come down to the improved workflow though, especially with it being kind of a sore spot in UE3, so I'm still waiting to hear more about that. OneEightHundred fucked around with this message at 03:20 on Jun 9, 2012 |
|
#
?
Jun 9, 2012 03:14
|
|
|
A lot of you are forgetting that the Source engine, one of the main competitors, has literal compile times anywhere from 2 minutes to sometimes even hours, depending on how large the map is, crashes very very frequently, has very limited support on particles, forces you to compile models into a specific format for the engine (and the tools for doing so are extremely outdated), and bakes lighting into the map (so it has very limited support for dynamic shadows). Heck, source didn't even have proper reflections on water until Portal 2 (they used cubemaps). Yes, you guys are saying "I made a deferred renderer a while ago etc", they've done it in such a way that it runs realtime with a lot of other stuff going on in the background, and I really like that. And "Now we have to use more particles or more polygons" isn't really an issue. You don't have to do anything. You can still make lowpoly games and have them look extremely nice, it's all about style. If your style is highpoly stuff, generally you won't frown upon support for higher poly. If your style is lowpoly stuff with cartoony textures, go wild! Unreal Engine 4 isn't just about the engine, but about the amazing devkit that comes with it. Heck, Unreal Engine 3 is pretty boring in terms of what it can do and actual specs, but the UDK is so so much fun to play around with.
|
|
#
?
Jun 9, 2012 03:41
|
|
|
Has anyone actually licensed Source in the last decade?
|
|
#
?
Jun 9, 2012 03:55
|
|
|
Paniolo posted:Has anyone actually licensed Source in the last decade? Wasn't Postal 3 going to use it? I'm similarly unimpressed, but not because it's old, but because I don't see how accurate time and day simulation, GPU-accelerated particles, etc. actually helps a game in any respect. Metroid Prime and Paper Mario still look better than a lot of the stuff that come out today, and that's because of an excellent art team, not because they get realtime volumetric soft-surface scattering. The real-time editor stuff was the only thing that impressed me, because it looked like a neat workflow. The polish on the Kismet looked awesome, with all those fancy wires and arrows, but I still have my same reservations about Kismet, and when looking at the planetary demo, all I could think was "I could write a for loop in three lines of code, I don't want to point and click away at this mess, making the same modifications to every single planet" Suspicious Dish fucked around with this message at 04:02 on Jun 9, 2012 |
|
#
?
Jun 9, 2012 03:57
|
|
|
Suspicious Dish posted:I'm similarly unimpressed, but not because it's old, but because I don't see how accurate time and day simulation, GPU-accelerated particles, etc. actually helps a game in any respect. Metroid Prime and Paper Mario still look better than a lot of the stuff that come out today, and that's because of an excellent art team, not because they get realtime volumetric soft-surface scattering. But that's the point I was trying to make. Yes, you now have access to all these particles and day simulation and whatnot, it does not mean you have to actually use them. They're just tools that people can use now to make higher quality games if they want, but again, the best part of this all is the actual UDK. And yes, you can write it in a for loop in three lines of code, so why don't you? There's nothing stopping you! You don't have to use Kismet at all! That's what I love about this all.
|
|
#
?
Jun 9, 2012 04:13
|
|
|
I don't understand why they don't build Google V8/Mono in to it or something, if they're sticking with Scaleform it would make sense. A lot of my job is making custom kismet nodes so the designers can get to work efficiently using properly encapsulated logic, for that purpose I like Unrealscript even if I did have to make some functional language structures before it felt right.
|
|
#
?
Jun 9, 2012 04:21
|
|
|
I would not call Source a serious competitor to UE. The only serious competitors for AAA titles are CryEngine, the new wave of publisher in-house engines that are seeing heavy reuse, and to a lesser extent Gamebryo. The only serious competitors for small games are Unity, XNA, and possibly PhyreEngine, though I guess CryEngine is trying to enter that space as well. Source has written off by pretty much everyone because of its atrocious workflow. Valve is reportedly working on new tools and has a lot of people devoted to that project, but until it yields results, I don't expect many licensees. I'm also not sure that Valve really cares about licensees either. Suspicious Dish posted:I'm similarly unimpressed, but not because it's old, but because I don't see how accurate time and day simulation, GPU-accelerated particles, etc. actually helps a game in any respect. There's really no doubt that fully-dynamic lighting is a big advantage, but they are late to the game and haven't really brought anything revolutionary to the table.
|
|
#
?
Jun 9, 2012 06:03
|
|
|
Is their real time global illumination using that deferred technique where you spawn hundreds of low intensity point lights? I don't remember the name.
|
|
#
?
Jun 9, 2012 06:48
|
|
|
Paniolo posted:Is their real time global illumination using that deferred technique where you spawn hundreds of low intensity point lights? I don't remember the name.
|
|
#
?
Jun 9, 2012 23:38
|
|
|
How do you guys feel about component architectures?
|
|
#
?
Jun 10, 2012 00:20
|
|
|
TJChap2840 posted:How do you guys feel about component architectures? We discussed them a bunch several pages back. I feel good about them.
|
|
#
?
Jun 10, 2012 00:26
|
|
|
Unormal posted:We discussed them a bunch several pages back. I feel good about them. Thanks. I read ever post, must have forgotten about it.
|
|
#
?
Jun 10, 2012 01:13
|
|
|
TJChap2840 posted:Thanks. I read ever post, must have forgotten about it. http://forums.somethingawful.com/showthread.php?threadid=2692947&pagenumber=112&perpage=40#post397148860 That's a post from the middle of the discussion, or so.
|
|
#
?
Jun 10, 2012 02:07
|
|
|
It can handle glossy inter-reflections, which is a huge step up from LPV. It also doesn't rely on inferring geometry from shadow passes, meaning it can handle more complex paths.Paniolo posted:Is their real time global illumination using that deferred technique where you spawn hundreds of low intensity point lights? I don't remember the name. You're thinking of Instant Radiosity (or one of several derivatives) -- this isn't that.
|
|
#
?
Jun 10, 2012 03:16
|
|
|
Random content generation: After getting a random spawn zone working, my gut is telling me that it would feel more natural if instead of it being a per-object spawn chance, instead I went with a random-number-of-things-to-spawn (and then randomly placed them). The straight up per-object chance often results in no objects whatsoever, or too many objects, whereas I think if I randomized the desired total instead, I could add some clamping and make it feel more consistent. Thoughts? I think there's some roguelike devs in here, at least.
|
|
#
?
Jun 10, 2012 03:53
|
|
|
Shalinor posted:Random content generation: After getting a random spawn zone working, my gut is telling me that it would feel more natural if instead of it being a per-object spawn chance, instead I went with a random-number-of-things-to-spawn (and then randomly placed them). I'm running into this issue, myself, and my answers have been different for different types of objects. What kinds of objects and zones are you talking about? Is this a 'to get the flavor right' deal or a 'to get the loot distribution right' one?
|
|
#
?
Jun 10, 2012 03:58
|
|
|
OtspIII posted:I'm running into this issue, myself, and my answers have been different for different types of objects. What kinds of objects and zones are you talking about? Is this a 'to get the flavor right' deal or a 'to get the loot distribution right' one? Though would it change your recommendation if this were loot? Guessing loot HAS to be done with a per-region / target number spawn, since otherwise, you'd get some horribly funky distributions. EDIT: VV Huh, interesting way of thinking about it. Thanks! Shalinor fucked around with this message at 04:05 on Jun 10, 2012 |
|
#
?
Jun 10, 2012 04:00
|
|
|
Shalinor posted:Random content generation: After getting a random spawn zone working, my gut is telling me that it would feel more natural if instead of it being a per-object spawn chance, instead I went with a random-number-of-things-to-spawn (and then randomly placed them). It's a reasonable re-factoring of the same problem. Ultimately, if what you want is some final product in a range of random states, it would be easier to determine the state you want (number of objects) and then decide if it's an acceptable starting point for the rest of the process (placement). To put it another way, if you generate the number of objects first, you're generating your content in a "most important to gameplay to least important" order, which allows you to do much more natural filtering and refinement.
|
|
#
?
Jun 10, 2012 04:04
|
|
|
TJChap2840 posted:How do you guys feel about component architectures?
|
|
#
?
Jun 10, 2012 04:30
|
|
|
Hubis posted:It's a reasonable re-factoring of the same problem. Ultimately, if what you want is some final product in a range of random states, it would be easier to determine the state you want (number of objects) and then decide if it's an acceptable starting point for the rest of the process (placement). One other thing you could consider is to figure out the total number you want at a somewhat higher multi-zone level, and do a pre-pass where you hand out the content based on an underlying noise map or something, so you fade cleanly between areas with way more of X and way less of X, while leaving the overall distribution what you want on average. Then you can play with the basis functions of your noise map to make it however smooth or irregular you want. Some areas will have slightly more than planned, and some will have slightly less, but they'll relate to each other in a way that player's brains will track. That way each zone doesn't present a very regular amount of whatever it is, helping alleviate some of the monotony of procedural generation of areas. One thing I'm considering for future engines/additions is several noise maps of simple properties, overlayed so that I can pick local minima/maxima of those noise maps, and combinations of noise maps, to place features. So like at local maxima of the combination of "dangerous" and "ruins" overall property maps, I could place a boss tower, or whatever. I hope that doesn't sound like too much schizophrenic rambling. Unormal fucked around with this message at 05:54 on Jun 10, 2012 |
|
#
?
Jun 10, 2012 04:42
|
|
|
The death of unrealscript is a wonderful thing.
|
|
#
?
Jun 10, 2012 05:10
|
|
|
Shalinor posted:It's a flavor one. This is for spawning decorations, in particular. Though the same solution would ideally work for spawning gameplay elements as well (it's built to be pretty generic). Furniture and map features are really hard! I say break it down into pre-built(ish) themes and use those to determine stuff. Or, well, I'll just say what I'm doing because what I just said is really vague. I give each room a 'theme' that's assigned semi-randomly, and that theme determines how items get placed. Usually there are a core set of furniture items that I slap down for sure to keep the room from being empty (a bed in a bedroom) and then from there I check the room size and figure out how many other objects it could use and what odds any given one of those objects will be of any given type. Then for treasure I actually do the % chance of each thing spawning deal (with some modifications). Every furniture object that's a container has a list of items classes that might appear in it (1 in 4 chance of "coins" being in this barrel), and depending on if I need to throw down more treasure or not into the dungeon those 'coins' might be a nice stash or a single gold-piece somebody lost. Err, so I guess what I'm saying is that I try to use both methods, and you probably should too. I actually think a lot of swingyness in scenery distribution is potentially fun and ends up creating a lot of emergent story content in the players' minds. I also say that loot distribution has a lot more room to be funky than scenery (at least as far as distribution per room goes, per level needs to be controlled pretty carefully), since half the fun of loot is fighting on through the dry periods and rejoicing when the big payouts finally come. Oof, talking about these things is scary if you haven't seen the other person's project directly, since slightly different designs require very different techniques. Could you give us an example of a given zone that the player might walk in on, what they're currently likely to find in it, and what you'd like them to find in it? Unormal posted:One thing I'm considering for future engines/additions is several noise maps of simple properties, overlayed so that I can pick local minima/maxima of both noise maps, and combinations of noise maps, to place features. So like at local maxima of the combination of "dangerous" and "ruins" overall property maps, I could place a boss tower, or whatever. This sounds like it could be amazingly cool if done right. One of the big things I'm trying to implement is a lot of zonal predictability, so players have the option of taking patterns they see and using them as information to figure out what's probably waiting ahead of them instead of just being totally at the whim of a RNG. A nice blobby noise map could maybe do that really well.
|
|
#
?
Jun 10, 2012 05:47
|
|
|
What I'm doing is for an infinite runner/platformer, so my requirements are a bit different. I'm also using Wang tiles for the regions, which lets me do a mixture of hand-placed vs procedural stuff. For the moment, I'm using a bunch of linear spawners (ie. they spawn things along a line you specify) per cell, and you can give each spawner a specific item it can spawn for each of its major divisions (an object it spawns at its halfway mark, an object it spawns at both of its thirds divisions, and object for its three fourths divisions, etc). Those "objects" can themselves be entities that spawn one of a random set, within some random offset of the target point. They can also be hierarchies of random objects. As per the above tweak, each linear spawner is now given a min/max count to spawn per item, and it randomly drops those in to the slots of whichever set of divisions for which that item was defined. So, each cell has the "wall decoration" layer, and I might design one cell to be for the "fancy castle" theme, and make those decoration items be stuff like "some sort of fancy sconce / torch / etc at the tenths, pillars at the thirds, some random windows (with hierarchically random drapes) at the fourths". Then there's the background objects layer, within which I might drop a linear spawner that can spawn a "table" at its half point, with that table in turn containing some linear spawners that throw a random number of chairs along either side at its tenth divisions. Etc. I might even make a variant of the linear spawner that mirrors all its spawns across it center, for items like pillars that can't appear completely at random. ... this probably just sounds like more crazy ramblings. It's kind of hard to talk about procedural stuff without disappearing up your own sleeve. But that's what I'm doing. Still not sure how I want to design the gameplay plane, where you're getting obstructions, breakables, etc. It'll use a variant of the same tech, but I'll need to pass over the spawned objects with a sanity check. "No jumpables directly beside eachother", "ratchet down the spacing as difficulty increases", "no X if you don't have that power", etc. I'm guessing that those same logic layers would make a lot of sense to throw into the decoration layers, if I wanted it to seem less random and more designed. But, I can get away with random decorations for now, so I'll start there, and leave fancier methods for a sequel, after I've figured out designed-random systems for the gameplay critical stuff. Shalinor fucked around with this message at 06:13 on Jun 10, 2012 |
|
#
?
Jun 10, 2012 06:06
|
|
|
|
| # ? May 27, 2024 06:16 |
|
|
That all sounds pretty good. I'd still worry about things turning too homogenous with a pure '1-4 things spawn per zone' technique, but if there aren't objects the player ever interacts with that might not be a problem. If I were doing what you're doing I still might use some secondary mechanism to change densities in a way that makes the background more patterned than totally RNGish, but that's going into personal taste zone. And for the record, none of the people saying they're afraid they're going into crazy rambling zone have actually done so. That said, I totally feel the same way about all my procedural posts.
|
|
#
?
Jun 10, 2012 06:33
|
|