|
Steampunk_Spoon posted:You generally want to atlas stuff that isn't supposed to tile and is always going to loaded together, like textures that all go on the same character or prop. Environment textures that tile are probably better off separate, that way the resolution they are displayed at isn't impacted by the size of your atlas (and you can tile them, obviously). Depending on the size of your environments having like 4 separate materials that tile is going to better on your memory use than putting every bit of mapped geometry into several giant atlasses, too. Also keep in mind that generating PBR maps for an atlas that contains different materials is going to give you very inconsistent results (plaster should probably have a different smoothness value compared to brick or concrete for example). That makes sense... thanks!
|
#
?
Mar 14, 2020 20:47
|
|
|
|
| # ? Apr 23, 2024 22:29 |
|
|
Hmm. I finished enabling my scaling unit AI system so that so that the more time that FixedUpdate takes to process, the fewer units in the queue get checked per FixedUpdate (ideally keeping the time steady even with lots of units in the scene). I expected the number of units checked per frame to drop precipitously as I added a shitload of units into the scene, since the collision avoidance code naively checks against every other unit's position at the moment. In reality though, the number of units processed per frame stayed almost exactly the same. Which means something else is, as a baseline, eating way more CPU than my lovely exponential-order-of-operations-growth collision anticipation code.  e: Pity the deep profiler hard-locked my machine due to running out of memory after a few frames. I feel like this is a bad sign.
|
|
#
?
Mar 14, 2020 21:55
|
|
|
I'm officially back to working on my project  until Animal Crossing comes out in a week then lord have mercy on my soulI don't have much to show off, but today I implemented camera re-centering https://i.imgur.com/cEpMRvP.mp4 although it doesn't look like much has changed, I've redone the entire structure of skelly's Animator Controller! Butting my head against that and trying to come up with a solution is part of why I haven't been working on it for a while, but I suddenly had a flash of inspiration and it turned out wonderfully! Basically my problem was that states in the animator are equivalent to animations, and a lot of animations can transition into each other (especially stuff like almost anything->falling) but I also wanted a way to keep track of "player states" in a more broad sense. Finally it dawned on me that I could represent each "player state" by its own state machine, resulting in my current much more readable and extendable graph:  (swimming not quite implemented yet) within the sub-state machines are the various actions that the player performs in that "state" such as rolling, crouching, doublejumping or climbing and as soon as the player's state changes (such as no longer being grounded) the control switches to another state machine. The way it's set up means that I can also extend it to work with any character as long as they implement a couple of variables such as IsGrounded, forward and vertical speed, and since it's not tied to direct input in any way it doesn't matter if those variables are set by the player, an AI, a scripted cutscene or whatever. The animations will transition as they should regardless! I don't know why I never thought of this before, but to be fair there's hardly any info to be found online about setting up an Animator Controller 
|
|
#
?
Mar 15, 2020 06:17
|
|
|
Perpetual Motion posted:So, I've been toying around with making an adventure game of some sort. Lots of choosing where to go and objects to examine and choices to make, that kind of thing. I can code it just fine, the problem is in the script writing. A simple word processor is not quite up to the task. With the amount of individual descriptions and lines of dialogue and branching choices that can pop up in a very variable order, things get messy and impossible to navigate incredibly quickly in something like Word or Google Docs, and figuring out how to organize it all is nigh-impossible. Anyone have any suggestions for programs to use for writing/organizing a script/collection of smaller documents for that kind of game? Maybe you might find Ink useful?
|
|
#
?
Mar 15, 2020 18:03
|
|
~*
~*
|
Your Computer posted:I'm officially back to working on my project Man those little breakthroughs are the best  More improvements to the cutscene controller. I can mess about with the player now! And I made wobbly rainbow text!
|
|
#
?
Mar 15, 2020 20:22
|
|
|
free Trapt CD posted:Maybe you might find Ink useful? Thanks for the suggestion! I did come across Ink and consider it, but I'd already had an engine picked out to work with the mechanics I wanted to use and didn't want to change. I eventually come up with a system, though, using a combination of methods. I've made a flow chart in Google Drawings mapping out the general sequence of the available options, with individual pieces on the chart linking to a bookmarked paragraph/sentence in a separate document for easier navigation. I could probably do better if I was willing to spend money on proper software, but I have a budget of approximately zero dollars right now, so this'll do.
|
|
#
?
Mar 15, 2020 20:53
|
|
|
Shoehead posted:Man those little breakthroughs are the best This is amazing. I love the goofy stuff people write when they're testing stuff. I honestly think "temporary developer text" could be a pretty good theme for a game. Just every single text box is the developers rambling about chilis or having their characters spout absurdist nonsense or making meta-commentary, literally all of it. Like, it'd be a very weird game, but I think it could work. Ironically it would require a lot of skill to write well. Here's my work for today: https://twitter.com/byobattleship/status/1239296593666473986
|
|
#
?
Mar 15, 2020 22:54
|
|
|
A procedurally generated metroidvania map is something that could've been a killer feature several years ago, but makes little sense now. Back when all we had were literally Metroid and Castlevania games, the idea of a new layout every time you play must have sounded appealing, but nowadays I'd say "Why would I ever play this more than once when I could play an entirely new game instead?" I don't think I would, now that there's an effectively endless supply of high quality metroidvanias available for dirt cheap. Ori 2 is on Game Pass right now. If I'm not satisfied after that, I've got Guacamelee 1 and 2, Owlboy, The Swapper, Yoku's Island Express, and more all from absurdly inexpensive bundles. By the time I could be done with those, Hollow Knight 2 will probably be available for $15. The over-saturation of the genre has killed the feature dead, like those murderers in Bloodstained: Ritual of the Night.
|
|
#
?
Mar 16, 2020 00:48
|
|
|
Nah, you only have to look at the surge in randomizer mods for classic games in recent times to see an audience does exist for procedural metroidvanias (and other procedural variants of known genres).
Chev fucked around with this message at 01:22 on Mar 16, 2020 |
|
#
?
Mar 16, 2020 01:13
|
|
|
Chev posted:Nah, you only have to look at the surge in randomizer mods for classic games in recent times to see an audience does exist for procedural metroidvanias.
|
|
#
?
Mar 16, 2020 01:33
|
|
|
Lork posted:A procedurally generated metroidvania map is something that could've been a killer feature several years ago, but makes little sense now. Back when all we had were literally Metroid and Castlevania games, the idea of a new layout every time you play must have sounded appealing, but nowadays I'd say "Why would I ever play this more than once when I could play an entirely new game instead?" I don't think I would, now that there's an effectively endless supply of high quality metroidvanias available for dirt cheap. The popularity of randomizers seems to indicate that there is a hunger for replayability, at least, and each of those games feels different enough that I can see wanting to play more of the one you love instead of playing a different one. But that's a strong argument for making a good game that can algorithmically remix itself for infinite second quests, not for procedural generation as the core of the game.
|
|
#
?
Mar 16, 2020 01:47
|
|
|
I think I see the point you're trying to get at -- why rely on computer-generated content when there's so much handcrafted content? But procgen is more than just that. Otherwise roguelikes would be dead as a genre because there's so many handcrafted dungeon crawlers out there, and that's demonstrably not the case. What procgen lets you do, as a player, is iteratively develop mastery over a system without being able to memorize your way through it. That's not something you can do by just picking up another handcrafted game and playing it start to finish. The new game's mechanics will be different, the skills (and degree of skill) it requires will be different. And that's not a bad thing...but sometimes I want to do another crossword puzzle even though I've done 400 crossword puzzles before. I don't want to do an anagram puzzle or a word search. In other words, procgen mostly isn't about "limitless content" in the sense of, say, enjoying exploring an infinite variety of worlds. It's about limitless content in the moment-to-moment gameplay. Nobody's going to look at a roguelike dungeon and say "ah yes, this level shows great distinctiveness" because it doesn't really. But the players will say things like "there's a really strong monster over there so I'm trying to find a way around it" or "there's a beholder and a squad of bee warriors here and I need to figure out how best to lure the warriors out so they don't get in the way when I fight the beholder" or "man I'm used to being able to roll over mutant goats but this character sucks at melee and I haven't found any guns yet, so this is tricky." They've dealt with similar scenarios before, but not identical ones. This is why procgen is so difficult, incidentally -- you have to nail the moment-to-moment gameplay in addition to making procgen that produces meaningfully different variations on that gameplay. Oftentimes games only manage one or the other.
|
|
#
?
Mar 16, 2020 01:59
|
|
|
Lork posted:Keyword "classic". People flock to randomizers for their favorite games of all time that they grew up with and have nostalgia for. The appeal of Link to the Past randomizer is that it's a way to breathe new life into the game that you've declared to be the best of all time since you were 12. Nobody cares about a randomizer for some game they haven't even played yet.
|
|
#
?
Mar 16, 2020 02:01
|
|
|
Lork posted:Keyword "classic". People flock to randomizers for their favorite games of all time that they grew up with and have nostalgia for. The appeal of Link to the Past randomizer is that it's a way to breathe new life into the game that you've declared to be the best of all time since you were 12. Nobody cares about a randomizer for some game they haven't even played yet. Lol I was too slow. I think there's something to this--people won't buy a randomizer just because it's a randomizer--but looking at the games that people randomize, it's not just the favorites of all time. It could definitely become one of those things like daily challenge modes that lots of games just have. TooMuchAbstraction posted:What procgen lets you do, as a player, is iteratively develop mastery over a system without being able to memorize your way through it. That's not something you can do by just picking up another handcrafted game and playing it start to finish. The new game's mechanics will be different, the skills (and degree of skill) it requires will be different. And that's not a bad thing...but sometimes I want to do another crossword puzzle even though I've done 400 crossword puzzles before. I don't want to do an anagram puzzle or a word search. Also this! This is where Spelunky shines, it teaches you how to read a level and get through it with the tools you have. But it's definitely easier to see how to do this on a tactical, room-by-room basis; I'm not sure if 'how to uncover the map' is the same kind of skill.
|
|
#
?
Mar 16, 2020 02:10
|
|
|
dreamless posted:Also this! This is where Spelunky shines, it teaches you how to read a level and get through it with the tools you have. But it's definitely easier to see how to do this on a tactical, room-by-room basis; I'm not sure if 'how to uncover the map' is the same kind of skill. When talking specifically about Metroidvanias, the skills you are testing are basically similar to any other realtime game -- defeating or avoiding enemies, traversing hazardous areas without touching the hazards, and so on. Reading the game map and identifying where you can progress is also a skill, but it's more high-level, less moment-to-moment. I guess noticing discrepancies in the room you're in and thereby finding secret areas could be a skill, depending on how the map generator works. But the main thing I feel Metroidvanias bring to the table here is that your progression is explicitly about gaining versatility, not just making your existing numbers bigger. I mean, bigger numbers can be present, but they're not mandatory, while "gain new techniques/equipment that let you progress while also being useful in its own right" is core to the genre. In particular, I feel like it's important that when you revisit earlier areas, they be easier not because you can just wade through the opposition thanks to your doughty healthbar and +15 mace of smiting, but because you're invincible on the rising part of your jumps and you got a freeze effect on your melee attack. Things that are qualitatively different. I think that lends itself very well to procedural generation, because the player's capabilities will be vastly different from one game to the next, dependent on your ability to come up with meaningfully different powerups of course.
|
|
#
?
Mar 16, 2020 02:31
|
|
|
I would argue that "metroidvania" in the strictest sense doesn't work well with procgen because the core gameplay is identifying where and when to advance as you acquire new abilities. If a roguelike is figuring out how to pass a challenge with the resources on hand then a metroidvania is figuring out what resources you need to pass a challenge. This is why timers and permanency are key to roguelike design, you need a way to push the player through challenges they might otherwise recognize as unconquerable. In Metroid you come to a high wall and instinctively you know to come back later. Rain World is the closest game I would call a successful blend of Metroid and procgen but it's still a game about forward progression and once you leave a biome you're not returning whereas a key element that makes Metroid stand out from the average platformer is how the world loops around itself to organically open new challenges.
|
|
#
?
Mar 16, 2020 02:43
|
|
|
al-azad posted:This is why timers and permanency are key to roguelike design I can point to a number of roguelikes (in particular including genre classics like Angband) that have neither of these. But trying to pin down "what is a roguelike anyway" was a recipe for frustration and flamewars even before the term got applied to approximately every game released on Steam from 2016 or so onwards, so whatever. You also disagree with me on what the core gameplay of a Metroidvania is. I say it's the moment-to-moment navigation of the world, not so much reading the map. I'll grant that reading the map is one of the skills that Metroidvanias require and most games don't, but I've never really felt like it was core to the genre. You can push the player forwards in Metroidvanias simply by locking the door behind them. This is something that bugs the hell out of me about a lot of modern Metroidvanias, that they don't do this. If the size of the currently-accessible portion of the game world only ever increases, then it becomes an immense chore to determine where to go next after each powerup acquired, especially with really big game worlds like in Hollow Knight. If you look at Super Metroid, it was frequently locking the door behind you by making you jump down shafts or go through shutter gates that closed behind you. By constraining your exploration to a relatively small area you force the player to figure out how they can proceed with the tools they have available. This can be misused; the most notorious example probably being the small section where you can get permanently stuck unless you learn to walljump. For added cruelty, there's a save station down there; if you use it, you can't even reload a save to get out. But that's more a failure of the game demanding the player perform a technique they had no real reason to believe they had (since you never acquire e.g. the Wall-Jump Boots) than it is a failure of map design. Anyway, all of this suggests that the "best" use of procgen in Metroidvanias would be to make a coffee-break roguelike, something where the session length would be maybe 30-45 minutes. Small worlds, fairly tightly-constrained, with rapid evolution of the player's abilities and rapid ramping of the difficulty curve. By keeping the game world small you reduce the amount of space the player has to consider and make the game more about making effective use of the tools the player acquires.
|
|
#
?
Mar 16, 2020 02:57
|
|
|
Chev posted:If this were the case the entire family tree of roguelikes and roguelites and roguelikelikes, or mystery dungeons or those procedural infinite levels you tend to find in the late/postgame of many japanese RPGs/SRPGs/ARPGs/etc (and even in some platformers) and what have you wouldn't exist, but they do. There's nothing about the metroidvania formula that makes it inherently less fit to procedural variants compared to the multitude of genres that have already been experimented with since basically the dawn of video games.
|
|
#
?
Mar 16, 2020 03:11
|
|
|
I think A Robot Named Fight handles being a Roguelike Metroidvania fairly well. It is focused on single-session games, but it always loops around in an interesting way and uses backtracking well. Most importantly for a replayable Metroidvania, almost all obstacles have multiple potential power-ups, meaning seeing an obstacle doesn't automatically tell you what weapon or ability you need to bypass it.
|
|
#
?
Mar 16, 2020 04:01
|
|
|
TooMuchAbstraction posted:I can point to a number of roguelikes (in particular including genre classics like Angband) that have neither of these. But trying to pin down "what is a roguelike anyway" was a recipe for frustration and flamewars even before the term got applied to approximately every game released on Steam from 2016 or so onwards, so whatever. Starvation is the timer. Whether it's getting hungry, being chased by a monster after X turns, or equipment durability the idea of the "timer" is to push the player and force them to think of new ways to challenge familiar scenarios. If Samus' varia suit could permanently degrade every time she falls in lava it would make for an intensely frustrating experience. And yeah I don't consider the moment-to-moment in a metroidvania to be its core because the genre is like the "immersive sim" in that it's greater than the the sum of its parts. Metroid has largely been mediocre as a straight platformer with floaty controls and Igavanias are RPGs where stats are weighted more than skill: that's not to say no skill is required but unlike traditional Castlevania you can brute force through most post-Symphony games. The best elements shine through in how the player organically reads the map and intuits how to navigate the play space. Like Super Metroid leads you down a linear path until you get the shiny new item but its trademark is having the player navigate backwards with that new insight hopefully guiding the player to all the things they've missed on the way down A lot of this is semantic arguing and abstract subjective ideas of "game feel" but the idea of a 45 minute small, tightly paced game sounds like Spelunky and is anti-Metroidvania to me. The world has to be big because by discovering new items you're making the distances traveled much smaller.
|
|
#
?
Mar 16, 2020 04:23
|
|
|
al-azad posted:Starvation is the timer. Whether it's getting hungry, being chased by a monster after X turns, or equipment durability the idea of the "timer" is to push the player and force them to think of new ways to challenge familiar scenarios. If Samus' varia suit could permanently degrade every time she falls in lava it would make for an intensely frustrating experience. Sure, and Moria/Angband have a town at the top of the game where you can buy food/light for a pittance, and dungeon levels infinitely regenerate every time you return to them so there's an unlimited supply of money/experience as well. They have no timers forcing the player onwards, except if you're still very early on where lack of understanding of the game mechanics can result in you running out of food/light. I'm not saying that some kind of forcing function isn't extremely common (though I'd hesitate to say that it's the norm, at least these days). I'm just saying that pointing to any one thing and saying "this is what defines a True Roguelike" (and not to say that this is what you were doing) is a losing proposition. quote:And yeah I don't consider the moment-to-moment in a metroidvania to be its core because the genre is like the "immersive sim" in that it's greater than the the sum of its parts. Metroid has largely been mediocre as a straight platformer with floaty controls and Igavanias are RPGs where stats are weighted more than skill: that's not to say no skill is required but unlike traditional Castlevania you can brute force through most post-Symphony games. The best elements shine through in how the player organically reads the map and intuits how to navigate the play space. Like Super Metroid leads you down a linear path until you get the shiny new item but its trademark is having the player navigate backwards with that new insight hopefully guiding the player to all the things they've missed on the way down The problem with big worlds is that they multiply several problems. The big one is that it's hard to make memorable procedurally-generated content, which makes the "where do I go next" problem harder to solve. If Super Metroid wanted you to remember a location, it'd put something there that you'd never seen before, like a big statue or a door with a different color. It could carefully allocate important details to areas that you would need to return to later, and then when you got a new ability you'd have a relatively small number of locations to check. This works (for your first playthrough at least) because it can regulate what you've seen before and what you haven't. But in procgen, this is harder, because you're constantly re-using a comparatively small library of content. Unless you're going to StyleGAN yourself some procedurally-generated statues (something I have semi-seriously considered) you can't really do this for procgen content. When nothing is really memorable, you need to place fewer demands on the player's memory, and small worlds help with that. A secondary concern is simply one of pacing. The early games of Metroidvanias tend to be samey because you don't have any kit yet, but you don't want to just dump a bunch of stuff on the player immediately. So you're going to spend a decent chunk of time ramping them up. You want to keep this interesting -- roguelike early games have a bad habit of being dull -- and one way to help with that is to make it go as quickly as possible. But it'd be a bit weird for the game to be, like, you get 75% of your kit in the first 25% of the game, and then 25% in the remaining 75%. The later part would seem to drag on as you don't get nearly as much progression on your power curve (things are expected to flatten out, I'm just saying they'd flatten out too much). If you can keep everything zippy then that solves that issue, at the cost of the game being short. But really the reason why I want a short game is because these days I don't really have the time to invest in a multi-hour procgen permadeath game. So it's at least in part a matter of preference. Of course a larger world and a longer game is doable; it's mostly just a matter of what feels best. Metroid26 posted:I think A Robot Named Fight handles being a Roguelike Metroidvania fairly well. It is focused on single-session games, but it always loops around in an interesting way and uses backtracking well. Most importantly for a replayable Metroidvania, almost all obstacles have multiple potential power-ups, meaning seeing an obstacle doesn't automatically tell you what weapon or ability you need to bypass it. ARNF is a good game, no question. I'm really impressed with what the devs have done. I want to do more (in particular, building a world where the building blocks aren't rooms, but sub-room components) but I can't blame them a bit for the design decisions they made. And of course, their game actually exists.
|
|
#
?
Mar 16, 2020 05:45
|
|
|
sorry to interrupt the roguelike metroidvania talk but I have One of Those Questions™ again I've ran into another thing where it's easy to find a solution but all of them feel like hacks more than actual solutions, and I feel like this is one of the things I wanna get right - slopes. Specifically, handling walking/sliding down slopes in a sane way. Googling the topic brings up a hundred questions and a hundred solutions, such as adding several extra colliders, forcing -9000 gravity, doing a raycast and snapping the player to the slope, and so on. I guess my answer is this; do any y'all have any experience with this and what would you recommend? I'm not really happy with any of the solutions I've found online since they kinda just brute-force that one specific thing and are prone to causing issues elsewhere, or they're just massive overkill. to not have a post entirely without content, here's some insight into my incredibly sophisticated debugging methods  the answer was yes
|
|
#
?
Mar 16, 2020 06:17
|
|
|
Your Computer posted:doing a raycast and snapping the player to the slope That's my favorite. But in general when I'm moving a player on a walkable surface I move them parallel to the surface, and have some amount of vertical slop both ways so bumps and curbs don't block them or force them airborne.
|
|
#
?
Mar 16, 2020 07:07
|
|
|
do the 3d version of how i handle angled corners, have a bunch of medium-sized overlapping hitboxes that move the player at a y velocity equal proportional to their current speed relative to the grade of the slope where the 3d comies in is you'll have to add in a gravity check that gently drags the player toward the height of the ground at their xz coordinates
|
|
#
?
Mar 16, 2020 07:31
|
|
|
dreamless posted:That's my favorite. But in general when I'm moving a player on a walkable surface I move them parallel to the surface, and have some amount of vertical slop both ways so bumps and curbs don't block them or force them airborne. this is one solution I've been thinking of, though I'm not quite there yet with the implementation  I figure this is probably something that can be done super easily with quaternions but as I've stated previously quaternions are basically black magic to me. Another problem I've not quite figured out yet is that I'm using the built-in Character Controller for collisions and it only considers itself "grounded" if there's a downward force being applied. I've gotten around this with a bit of a hack just setting the downward velocity to like -0.5 or something while on flat ground but it obviously runs into some trouble now that I'm dealing with slopes I mean, I know exactly why it behaves like it does - as I move down a slope the velocity moves me off the slope and into the air, and the gravity pulls me down on the slope again the next frame so I end up stuttering down the slope in lots of tiny "falls". That's why I figure the solution must be something like aligning the velocity to the ground normal in some way.
|
|
#
?
Mar 16, 2020 08:16
|
|
|
Your Computer posted:this is one solution I've been thinking of, though I'm not quite there yet with the implementation Honestly the last time I tried this was a long time ago and I wound up not either not using the character controller or ignoring most of its functionality, so I'm not sure how much it's doing for you, but. You should be able to get the surface normal of the surface you're standing on (from the raycast, if nothing else) and then to make a vector parallel to that surface you just subtract out the amount of the vector that's perpendicular to the surface: Vparallel = V - (V dot N) * N. You can also use the surface normal to make sure your ground sticking force is pushing you straight into the ground.
|
|
#
?
Mar 16, 2020 08:48
|
|
|
Thanks! I'm making good.....  progress...  I think I'm gonna have to spend a bit more time on this one  I realize I have to rewrite some fundamental stuff because right now I'm naively applying a downward force, well.... downward. It's just directly applying to velocity.y. I feel like I'm on the right track though, so hopefully I'll have something to show for it soon. Here I was thinking I had most of the core stuff implemented and I just kinda.... forgot about slopes being a thing vvv yeah! that sounds like exactly the kind of thing I should be doing. I'll work on implementing it tomorrow vvv Your Computer fucked around with this message at 11:14 on Mar 16, 2020 |
|
#
?
Mar 16, 2020 10:36
|
|
|
One I got from an old, old paper (which IIRC cribbed it from Quake) that's been working reasonably well is to separate the movements induced by walking and gravity, ie instead of applying that downward force to velocity, you move without gravity along the expected direction for walking (ie based on the local slope) then, on the same update, move downward with solely gravity.
|
|
#
?
Mar 16, 2020 10:49
|
|
|
I'm so glad people run into the old "My game logic thinks you are falling up or down slopes" even in 3d! I've been feeling the itch to work on some platformer stuff soon, maybe once my gov mandated plague holiday comes up I could pop something out.
|
|
#
?
Mar 16, 2020 12:24
|
|
|
Slopes are hard.  The last time I tried to do a platformer, I in particular remember having issues where my character would just go flying off into space (horizontally) whenever they encountered a downslope. I seem to recall that the way some old games handled slopes was to push you down by an amount proportional to your horizontal velocity, with the proportion dictating the steepest slope they could handle. But in this day and age I'd be inclined to try the raycast approach first.
|
|
#
?
Mar 16, 2020 14:49
|
|
|
It kinda depends, some special case it (ie there are special behaviors for every semi-solid tile variant), some have a bunch of hacks. In general the biggest distinction is old 2d games don't abstract the player characters as solids for level collision purposes as 3d games usually do but use a bunch of sensors (points or rays). It's also well worth looking at/experiencing how some 3d platformers handled it. For example IIRC here's that thing you don't really notice until you pay attention in Mario Sunshine where it's basically impossible to make Mario stand on an edge, once he gets close enough he'll automatically snap to hanging off it/doing a small jump off it depending on your speed and whether there's enough room to hang, just to avoid the, well, edge cases. The half press youtube guy also made a humongous video on Mario 64 physics which is pretty crazy but these days the same behavior could certainly be achieved in less convoluted ways. Chev fucked around with this message at 15:07 on Mar 16, 2020 |
|
#
?
Mar 16, 2020 15:02
|
|
|
I don't have a lot to add to the slope discussion I'm afraid, except don't use the default character controller because it's not great. Always better to spin your own, even if you get half of it from some genius on the Internet. I have a dumb question of my own. Anyone know anything about tank physics? Specifically the tracks? I was trying to model it in Unity and it's real pain to get the feel right for a tracked vehicle even by fudging it with directly applying the forces to the rigid body. Using wheels then animating tracks over the top seems to be the "cool thing" to do on the asset store, but wheels in Unity make me want to jump out a window a little. I'd appreciate any suggestions I could try out before I give in and waste hours of my life writing my own tank controller which doesn't actually work
|
|
#
?
Mar 16, 2020 16:18
|
|
|
TooMuchAbstraction posted:Sure, and Moria/Angband have a town at the top of the game where you can buy food/light for a pittance, and dungeon levels infinitely regenerate every time you return to them so there's an unlimited supply of money/experience as well. They have no timers forcing the player onwards, except if you're still very early on where lack of understanding of the game mechanics can result in you running out of food/light. It doesn’t matter that the resources are infinite, the objective is to manage pacing. Unless your going Ironman you will need to leave the dungeon to restock and that push-your-luck element naturally creates tension. Rogue likes are derived from dungeon crawlers which are ostensibly resource management logistics games. If modern character based role playing games are “how do I get this treasure” then dungeon crawlers are “what do I DO with the treasure?” I’m not here to argue what is/isn’t a rogue like, I’m here to say I can’t think of a single proc gen permadeath run-based game without resource management because that is the crux of their design whether it’s a literal timer or a resource that forces you to the surface. And that aspect is antithetical to the Metroid style where your resources are keys and thus must always be supplied to progress.
|
|
#
?
Mar 16, 2020 16:25
|
|
|
TooMuchAbstraction posted:Slopes are hard. Yeah after using raycasting to do soft collision on edges in the Zelda project (which feels so gooood) I'm pretty confident I could fix a lot of the issues I was having with platformer feel last time I worked on one. Just smushing around corners and up and down slopes. Speaking of the zelda project. I'm doing story stuff https://twitter.com/Shoehead_art/status/1239569843210371072
|
|
#
?
Mar 16, 2020 16:26
|
|
|
al-azad posted:I’m here to say I can’t think of a single proc gen permadeath run-based game without resource management because that is the crux of their design whether it’s a literal timer or a resource that forces you to the surface. And that aspect is antithetical to the Metroid style where your resources are keys and thus must always be supplied to progress. Hmm, interesting metric. I guess a lot of roguelites don't qualify under that definition, since I assume you're talking about a resource that must decrease (or at any rate can't increase) so long as you aren't making progress. Which rules out resources like Binding of Isaac's health/bombs/keys, or 20XX's health/weapon energy. Something more like Teleglitch's ammunition would qualify though, as you have to use ammunition to defeat enemies (knifing everything isn't practical). It is of course possible to make a Metroid game where you just have a timer to get your mission accomplished before the planet explodes, but that's kind of coarse. But it's also entirely possible to have a resource (air, food, batteries, etc.) that needs to be replenished by exploring the map. Find single-use recharging stations, that kind of thing. Like, I get how having limited ammo could be problematic because what happens if you run out of ammo and then encounter an exploration barrier that requires ammo to bypass? But just...take that into account when designing the game. I don't think it's impossible to make a Metroid roguelike where you have limited resources but can never get stuck by those limited resources.
|
|
#
?
Mar 16, 2020 17:23
|
|
|
al-azad posted:
Cardinal Quest? Like there's a shitton of roguelites that don't have a ticking timer mechanic
|
|
#
?
Mar 16, 2020 17:41
|
|
|
al-azad posted:I’m not here to argue what is/isn’t a rogue like, I’m here to say I can’t think of a single proc gen permadeath run-based game without resource management because that is the crux of their design whether it’s a literal timer or a resource that forces you to the surface. And that aspect is antithetical to the Metroid style where your resources are keys and thus must always be supplied to progress. It doesn't have to be permadeath-based though. Resource management comes with permadeath which is characteristic of the roguelike model but that's not the only angle, the interesting thing is with procgen you shift from knowledge of the map to knowledge of the rules, so you can explore a different play space. Take Ultima Ratio Regum, where the concept is the game generates history and cultures along with its world, DF-style, and then the professed goal is to have you find out what parts of said history don't fit the observed patterns and have been falsified to hide a conspiracy that you have to root out. Take Papers Please, which is literally about knowing the rules and then trying to survive while bending it just enough to more closely fit what you think should be the spirit of the law. You could make a procedural murder manor in which the player is the detective who can explore the generated timeline, guests and murders for clues to foil the mastermind, you could use Midwinter II's (which had a procedural but fixed world but where the idea could be extended to random worlds) concept where you have to understand how the local geography and politics influence an incoming invasion that obeys specific pathing so you can then derail it through freeing the right places, etc. There's just tons of possibilities for rules-based play. Since in metroidvanias a lot revolves around the "castle"'s layout, then procedural play could be built around the understanding of that castle. Maybe accessing the final boss, the true ending or the local inverted castle equivalent requires you to observe how the world is put together and what key fits where. I remember an old article on gamasutra, about mysteries in games I think, where they had the fairly simple but extendable example of a game where if you observed the layout of the world you could guess where secret rooms should be because of gaps and your knowledge of the world's general shape (a pyramid in that case). There's a lot that can be explored as to how to hint that a space exist but you haven't found the route to it yet, or that you should wear specific glasses against a given enemy, or hints to weirder rituals that'd seem more like something out of druaga. There's also quite a few things that make it interesting purely from a generation perspective, as you want a world that wraps on itself instead of the more dungeon-esque progression you usually get, and there's the whole history approach, too, like the idea that the castle/world is built as different layers that got stacked or renovated based on the in-game history (like in souls games where walking through geography is akin to moving through that game's history) or multi-game history (where castle areas often refer to areas found in previous games, same for relics, etc so maybe if you get the in-game historical information that once upon a time a Belmont dug up 5 body parts to get an audience with the lord of the castle you can guess that you're gonna have to do the same). Heck, you could take the multi-game castle history thing more literally and go with an Infinity Blade-esque setup where each time you die your child takes over 20 years later and the castle's been partially rebuilt/expanded/refitted with new monsters and bosses, possibly based on what you did and took the previous time, so your previous map still applies somewhat but finding out what changed will be key to survival. There's lots to explore there and we're barely at the surface of those kinds of play spaces. Chev fucked around with this message at 22:38 on Mar 16, 2020 |
|
#
?
Mar 16, 2020 18:34
|
|
|
made some acid https://twitter.com/PorbleG/status/1239620577696120834?s=20
|
|
#
?
Mar 16, 2020 19:33
|
|
|
This apparently launched today in alpha: CORE, a game creation tool built on top of UE4 (yes). https://www.youtube.com/watch?v=0WgYeDm9lz8 Huge Fortnite vibes from that trailer and they don't show the actual UI at all, which seems dumb but that's their marketing angle, I guess. The website has some screenshots. The distinguishing "features" are that you can very quickly smash together a working game prototype and publish it, there's Lua scripting and you cannot import any of your own assets - everything is created within the client from prefabs, much like Dreams for the PS4. I watched the announcement stream and they were talking a lot about people being able to make "their own battle royale", which... dunno, I guess there's a crowd out there that wants something like that? I'm more interested in how this compares to Dreams overall, especially when it comes to sharing creations or collaborating. I asked about importing audio and the answers I got were that I could create my own music with their libraries and generators or maybe use a Lua script to emulate MIDI. Someone asked about creator ownership and they said the creators would own the IP but since all assets are baked into the platform and anything you make is ultimately derived from their stuff, you own essentially nothing you create. Nothing about monetization yet but it sounds like these guys are going after Roblox. Documentation here.
|
|
#
?
Mar 16, 2020 19:38
|
|
|
|
| # ? Apr 23, 2024 22:29 |
|
|
An endless universe of games and worlds as long as what you've got in mind is a shoddy Fortnite ripoff, eh?
|
|
#
?
Mar 16, 2020 20:11
|
|