|
Lunatic Sledge posted:what's up I just cranked out a gauntlet-style hangman game with random words (from a list of like, 100+ wild west themed words) and a leaderboard and poo poo Nice!
|
# ? May 23, 2020 04:46 |
|
|
# ? Apr 26, 2024 20:36 |
|
I felt pretty burned out after releasing my iPhone game about a year and a half ago, but have finally had some game dev energy return to me. I'm just looking at doing some weekend hobby stuff this time around, I think being "full indie" once was enough. Despite having spent over a year in Unity ramping up / making my game, I feel like I'm a little overwhelmed by all the different options available with multiple (incompatible?) pipelines and other changes Unity has made since I last paid attention. I guess for 2D it doesn't matter as much, but I'm thinking maybe I'll give Godot a try. Is the C# support good?
|
# ? May 23, 2020 04:56 |
|
If Godot C# isn't a first-class citizen quite yet, it's definitely gunning for it. I'm actually worried it'll become the primary Godot language at some point. Not that C# wasn't delightful when I last used it, but so's gdscript and also I get a wristful of Java at my day job.
|
# ? May 23, 2020 05:04 |
|
Hammer Bro. posted:If Godot C# isn't a first-class citizen quite yet, it's definitely gunning for it. funny, literally just mentioned this in the other thread, but I'm really not liking GDScript much. i have written quite a lot of Python for web development (though 2-3 years ago now, I guess), so I'm not really put off by the syntax or anything like that, mostly just wish the type annotations were more powerful (like, not "algebraic data types" powerful, just "let me define the items in an array" powerful), and the lack of list comprehensions and lambdas means my logic always ends up being a for-loop hell. also, I have introduced a couple memory leaks in trivial applications by just forgetting that it uses really naive reference counting and you have to explicitly free circular dependencies; I guess that might be okay as a runtime tradeoff to avoid GC but is just so weird to me in a scripting language in 2020 that said, I like it well enough that I haven't tried C# yet (I didn't even install the version with Mono support, which I guess would be required). It does seem like just about every example you find on the internet is in GDScript and not C#; I'm not familiar enough with the Godot C# API to know if it's an easy 1:1 translation
|
# ? May 23, 2020 05:12 |
|
Escape Goat posted:I guess for 2D it doesn't matter as much, but I'm thinking maybe I'll give Godot a try. Is the C# support good? It wasn’t great as of late last year, when I bailed on Godot while waiting for them to address some bugs I reported. GDScript has issues (the typed version was very buggy last I tried, for example), but I found it generally pleasant to work with, and reasonably well-supported in tools such as VSCode.
|
# ? May 23, 2020 11:05 |
|
Escape Goat posted:I've been playing a lot of Diablo-like games lately since I'm noodling around with making a Diablo clone, and trying to figure out why some of them feel so bland compared to D1/D2. I think the pain threshold / interrupt is one of the critical ingredients missing from some. So many action games stun the player but not the monsters that it really makes me wonder how much time people put into studying these games. There was a long period of FPS games in the mid-aughts that just had enemies tank shots and it suuuucked.
|
# ? May 23, 2020 11:56 |
|
Ranzear posted:New game design gripe: Randomly Optimal Enemies On the other hand, Monster Hunter (the actual best game series) has a lot of monsters that would be tremendously harder if they spammed their best move on repeat. I think they make it work because the monsters blatantly aren't intelligent opponents that are playing optimally; they're angry animals that are thrashing around using whatever natural weapons and abilities are available to them.
|
# ? May 23, 2020 12:21 |
|
I kind of blame Monster Hunter for a design conceit I don't like in encounter design that I call the GTFO Whirlwind. Whenever you have a boss that maybe doesn't move much they always have an attack where they spin around in circles in an unavoidable attack to knock you back. For a big dumb animal I get it, they're thrashing around out of control bucking and kicking, but it appears so often that I just find it lazy and frustrating you couldn't think of a cleverer way for an enemy to make some space. Have them teleport, dodge roll, jump, invincibility frames, block, parry, or anything the player would do to back out of a corner other than spinning. Bring up literally any boss from the Dead Rising series, I hate it so much and never saw it prior to Monster Hunter that it seems to be a thing Capcom trademarked and everyone else copied over time.
|
# ? May 23, 2020 12:59 |
|
al-azad posted:So many action games stun the player but not the monsters that it really makes me wonder how much time people put into studying these games. There was a long period of FPS games in the mid-aughts that just had enemies tank shots and it suuuucked. I remember in the early days of TF2 they said something along the lines of "we don't have big knockbacks or stuns because whenever a player loses control of their character, they become frustrated". That poo poo lasted all of two seconds, along with their "recognizable silhouette" design rule.
|
# ? May 23, 2020 13:26 |
|
As someone who is making a game where the player units and the enemy unit are the same, trust me it's easier the other way. Making these enemies a challenge for a player is something I'm having to spend a lot of time on.
|
# ? May 23, 2020 16:14 |
|
Thanks for the kind words, everyone! After having spent most of the last year (criminy) on building systems, it's proving surprisingly straightforward and fun to add more content. I'm just worried that my later bosses won't be able to live up to the standard I'm setting here. I'm definitely gonna need to jazz up the Biggest Gun boss; just having a giant gun sitting in a volcano really isn't gonna cut it.BoneMonkey posted:As someone who is making a game where the player units and the enemy unit are the same, trust me it's easier the other way. Making these enemies a challenge for a player is something I'm having to spend a lot of time on. Yeah, if you're doing, like, a tactics game where everyones' stats are within fairly tight bounds and you can't just say "the player takes 10% the damage that enemies do", balance becomes a lot harder. I think your best bet with that kind of thing is to try to include system bonuses that the player can take advantage of and the AI doesn't really pay attention to. Things like "if a leader unit is killed then their followers take a stat penalty", or "standing on forest gives you a defensive boost". I can just do "the AI deals 10% the damage the player does, and is less accurate, and fires less often" but I'm throwing dozens of units around per mission and it's not really practical for the player's lone unit to avoid all incoming damage.
|
# ? May 23, 2020 17:59 |
|
TooMuchAbstraction posted:I'm definitely gonna need to jazz up the Biggest Gun boss; just having a giant gun sitting in a volcano really isn't gonna cut it.
|
# ? May 23, 2020 18:58 |
|
Chev posted:Remember the wisdom of Metal Slug: your giant gun can sit on a giant crab or shark. For a sense of scale, here's some doodles I made for this boss a few months ago: When I say "biggest gun" I mean it.
|
# ? May 23, 2020 19:20 |
|
Ranzear posted:New game design gripe: Randomly Optimal Enemies The company Raizing made scrolling shooters that, to this day, are considered some of the hardest out there. Not because of volume of bullets (though that definitely plays into it) but the sheer ridiculousness of some of the bosses they made. Enter: Black Heart/Black Heart MK2 https://www.youtube.com/watch?v=IoNmCZOBOQE&t=1596s These two bosses are absolute hell for most players, and alot of that has to do with the later stage of the fights. See, Both have an incredibly large selection of bullet patterns to pull from, and they tend to randomly pull from them. these start out fairly easy (depending on if you managed the dynamic difficulty multiplier well or not. YES THE WHOLE GAME IS TIED TO THAT BTW) and progressively get harder, while also pulling from a set of intermediary attacks of down-rushing you, rotating pattern, or bouncing pattern. You can't cheese these by flying ahead of the boss either, because it will then just fire really fast shots directly at you. What it does after taking set amounts of damage, though, is it starts pulling randomly two of the pattern set, then three near the end of the fight. You end up with a boss that's unpredictable as all get out, and you need to learn and process up to three of it's patterns at once by the end of it. And if you want to score optimally, you have to drag it's health down low and fully damage both wings to get the full score count possible. You end up with a boss that can either go in your favor or be an absolute run killer, and then the final boss also has some randomization to it's own attacks. Of course, they then one-upped this with the final boss of Armed Police Batrider, which has an insane pool of patterns to pick from as well as being a multi-form fight, but I don't know nearly enough to comment on it beyond what has been griped about over the years. Randomization in boss structure is really annoying, and they can either go well or be an absolute disaster. Usually, it's teetering on the latter.
|
# ? May 23, 2020 19:44 |
|
TooMuchAbstraction posted:For a sense of scale, here's some doodles I made for this boss a few months ago: so the train gun is a sidearm
|
# ? May 23, 2020 19:51 |
|
TooMuchAbstraction posted:I'm definitely gonna need to jazz up the Biggest Gun boss; just having a giant gun sitting in a volcano really isn't gonna cut it. Maybe after the boss takes enough damage the volcano opens up a mouth and starts barfing large horizontal beams of lava at you? I'm pretty sure at least 40% of all volcanoes are actually just giant angry faces that look like mountains. I'm pretty sure they'd get more angry the more they got shot. Oh, and if you could add the big flashing WARNING text during the boss reveal cinematics that'd be
|
# ? May 23, 2020 20:05 |
|
just got my latest beta up (for android) if anyone wants to try it out. its invite only so you'd have to PM me
|
# ? May 23, 2020 20:06 |
|
Chev posted:Remember the wisdom of Metal Slug: your giant gun can sit on a giant crab or shark. Hammer Bro. posted:Maybe after the boss takes enough damage the volcano opens up a mouth and starts barfing large horizontal beams of lava at you? Hammer Bro. posted:Oh, and if you could add the big flashing WARNING text during the boss reveal cinematics that'd be
|
# ? May 24, 2020 02:00 |
|
Hammer Bro. posted:Maybe after the boss takes enough damage the volcano opens up a mouth and starts barfing large horizontal beams of lava at you? This has potential, definitely, as a way to ramp up the fight as it progresses, so thank you for the suggestion! But really what I need is for the player to be laugh-crying as soon as they figure out what the boss's deal is. Like, "holy poo poo, this is so stupid and so perfect". Especially since this is the boss immediately before you dive into the volcano to go to an underground magma ocean where you fight the superweapon factory. In an ideal world, by this point we've trained the player to expect something really ridiculous and we still manage to blindside them. quote:Oh, and if you could add the big flashing WARNING text during the boss reveal cinematics that'd be of course, issue filed. Gotta have the boss warning siren!
|
# ? May 24, 2020 02:44 |
|
Ranzear posted:The answer is pretty clear now: Giant volcano-backed crab with the gun nestled in the volcano, which can submerge and reappear further away to charge and fire angry linear magma beams. Hit its weak spot for massive damage
|
# ? May 24, 2020 02:49 |
|
TooMuchAbstraction posted:This has potential, definitely, as a way to ramp up the fight as it progresses, so thank you for the suggestion! But really what I need is for the player to be laugh-crying as soon as they figure out what the boss's deal is. Like, "holy poo poo, this is so stupid and so perfect". Especially since this is the boss immediately before you dive into the volcano to go to an underground magma ocean where you fight the superweapon factory. have a decoy boss gun that's big and shoots a laser at you then when you get it down to half health the entire gun rises out of the volcano and you realize you were fighting the scope
|
# ? May 24, 2020 02:50 |
|
Cross-posting here now that it's (mostly) out of beta... I ported an old Mac game about flying a paper airplane that some of you might remember. https://github.com/elasota/Aerofoil/releases/tag/1.0rc1 ... including the level editor, and it has some tools for importing community content and extracting old StuffIt/Compact Pro archives. Triarii posted:On the other hand, Monster Hunter (the actual best game series) has a lot of monsters that would be tremendously harder if they spammed their best move on repeat. I think they make it work because the monsters blatantly aren't intelligent opponents that are playing optimally; they're angry animals that are thrashing around using whatever natural weapons and abilities are available to them. I think the issue with the Marauder, aside from having about 50% too much health, is that the biggest part of that "performance" is they have some discernable logic to their behavior and the Marauder... when you encounter it, the game literally tells you how it behaves and how to beat it, and both are wrong. If you try to deadzone it, its random zippy movement will move it out of the deadzone and then it will do the things that it tells you it won't do if you deadzone it. It tells you not to keep it too far away or it will just snipe you, but you can dodge its projectiles and then it will get bored and charge in for a melee attack anyway.
|
# ? May 24, 2020 08:32 |
|
OneEightHundred posted:Game "AI" in general is really about creating a performance, not any kind of intelligence. They're intentionally dumb. Yeah, this. The enemies in Bubble Bobble are almost completely deterministic, but they're hard as balls to defeat because the levels they occupy are designed to make them really likely to land on your head. One of the lessons I took away from making Robostar was how the enemies with very simple "move diagonally and bounce off the walls" behaviour weren't signficiantly less satisfying to fight than the ninjas which used pathfinding to hunt the player down, threw shurikens at a distance, and ran for cover and healed up when they were wounded.
|
# ? May 24, 2020 11:13 |
|
A huge mistake I mad starting out was thinking I should make enemies who are mirrors of a player character driven by ai trying to push buttons. It's bloody hard to do too. A recent mistake of mine is also thinking that if an enemy with a pattern is solved by the player easily it's essentially useless. I had to go play similar games to remember how easy some enemies in, for example, Link's Awakening can be. I was also feeling guilty about how sometimes some of my wandering ai would just walk into a wall. Started playing Minish Cap last night and Octoroks are just stuck on corners and poo poo, so if it's good enough for a weak enemy in a Capcom/Nintendo it should be good enough for me.
|
# ? May 24, 2020 12:10 |
Shoehead posted:A recent mistake of mine is also thinking that if an enemy with a pattern is solved by the player easily it's essentially useless. I had to go play similar games to remember how easy some enemies in, for example, Link's Awakening can be.
|
|
# ? May 24, 2020 14:00 |
|
Zereth posted:You generally don't just fight one of those alone in a room, is the thing. You'll fight like five of them in a room with some spikes, or a tight corridor, or they're just in the way on the path between point A and point B so it's not just 45 seconds of walking. Yeah, absolutely -- which is the other thing that is really critical to game design (and it's the thing I have to keep reminding myself of as a d&d GM too): the space you fight enemies in is as important as the enemies you're fighting in it.
|
# ? May 24, 2020 14:18 |
|
Shoehead posted:I was also feeling guilty about how sometimes some of my wandering ai would just walk into a wall. Started playing Minish Cap last night and Octoroks are just stuck on corners and poo poo, so if it's good enough for a weak enemy in a Capcom/Nintendo it should be good enough for me. Yeah, this is pretty common I think. When I was working on my ship steering AI I went and looked at Warship Gunner 2's ships, just kinda parked myself next to a fleet and observed them. And they crash all the time. An escort will steer in front of its flagship and get T-boned. Ships ground themselves. It's a total shitshow if the ships have to do more than just sail in a straight line. But when you're playing you don't really notice, because you're too busy shooting things. You only really look at each ship for a few seconds before it's time to move on to the next one, and you see a ship get stuck you just think "score, that'll make killing it easier". Which is why, even though my ships crash quite frequently, and sometimes will just full-bore ram the ground and never back up, I really haven't prioritized making them smarter.
|
# ? May 24, 2020 14:49 |
|
All these posts are right. But counter point, making a cool AI is fun as gently caress, and you should do it! Also utility AI is the best AI.
|
# ? May 24, 2020 15:14 |
|
Flying enemies are great because you don't have to make their AI give a poo poo about walls, so you can just have them wander around a little bit and shoot occasionally and you're done.code:
|
# ? May 24, 2020 19:41 |
|
I sat down to write the Game Flow section of my design document, ended up reducing it to a series of mostly yes/no decisions, and to my complete surprise ended up with an AI.code:
I highly recommend the thought experiment. Start at the starting point of your game, think of all the meaningful choices presented to the player at that point in time, write each one down, and repeat until you've mapped out your decision space.
|
# ? May 24, 2020 20:30 |
|
Depends on the game. For something like what I'm making, the search space would be literally impossible to store. The good news is the AI is going to be intentionally extremely simple. Like a tick or two above Conway's game of life.
|
# ? May 24, 2020 20:40 |
|
It's worth doing for the player character as well, which was my original intent though then I realized my AIs were also players.
|
# ? May 24, 2020 21:16 |
|
OneEightHundred posted:Cross-posting here now that it's (mostly) out of beta... I loved this game as a kid, must have been a Windows 3.1 / 95 version. Thanks for sharing!
|
# ? May 24, 2020 21:47 |
|
Hammer Bro. posted:It's worth doing for the player character as well, which was my original intent though then I realized my AIs were also players. That's what I mean - the player search space is gigantic. The "AI" is just a collection of very basic switch statements (I know that's true in all games, but in mine, it's literally exposed to the player and they can gently caress around with it).
|
# ? May 24, 2020 21:50 |
|
Shoehead posted:A huge mistake I mad starting out was thinking I should make enemies who are mirrors of a player character driven by ai trying to push buttons. It's bloody hard to do too. My AI for Caliber is written with what amounts to a driving direction vector, but in the end they're just fake players using the standard-rear end input object, some batching of several into a single worker, and some loopback connections. The vector points the way and some dumb function just controls the steering and driving inputs to get it moving. What generates that vector is the real 'AI'. Basically I get the position and type of thing and other properties and values my AI is aware of, create a unit vector in the direction of that object, and then feed the relevant other values (distance, health, energy, etc) into a somewhat bespoke funky curve to produce a positive or negative scalar to apply to the vector. Each vector generator handles a whole class of objects, so like 'enemy tank', 'capture point', 'enemy base', and most of the scaling is just some ratio of distance to relevant value. It boils down to a massive stack of curves which spit out a bunch of vectors that can be in all different directions and positive or negative meaning a whole lot of 'considerations' rather than any discrete decision making. All those vectors get totaled up, and then it's just translated into the regular-rear end player input object - steer left, steer right, drive forward, drive backward, and there's even a bit of null zone so they'll sit still if there's no real impetus, all based on that one final vector. So no, you weren't too far off-base here, you just need the logic layer separate from the translation layer. I have a single function that handles translating that single vector into movement inputs, and then a target-keeping system for aiming/leading and firing inputs, and some other logical junk just for module handling. With all that, I don't need to ever touch how it handles 'inputs' to be able to wildly change the logic behind them. I can throw a new vector generator in the massive pile, paying attention to some new object type or whatever, and as long as I scaled the output correctly it'll just mesh right in with everything else. Also, mirroring player inputs for your AI is good because when something isn't working you can at least rule that part out. Incidentally, I wrote this AI because I couldn't get goons to play my dumb tank game.
|
# ? May 25, 2020 13:02 |
|
Haha, that's basically what I do now. I used to have a ton of states, and have a list of input curves to determine what state to be in. ( Running away, running towards player, etc) Now I have 3 states, idle, moving and using an ability. Much smoother to have all the moving happening in one action. You get lots of very interesting behaviour this way. Like my enemy units will naturally kite and surround player units. Because they move away from the player units if they are too close, move towards the player units if they are outside weapons range and move away from ally units if they are too close. I did this style of AI because I didn't want to write behaviour trees for all the different types of unit. Now every action has its list of inputs and considerations and I can just add those list to each enemy type as needed. BoneMonkey fucked around with this message at 15:46 on May 25, 2020 |
# ? May 25, 2020 15:43 |
|
For those of you who model mid-detail characters (basically anything bellow 5-8k polys), how do you approach shoulders: by trying to match the topology to the real musculature, or the ps2 bendy-straw approach where the shoulders are basically just a 3-loop tube that feeds into the arm? I know that actually mimicking the musculature gets you much nicer deformations, but nearly all of the ps2/early ps3-era models I've looked at seem to do some variant of the straw approach.
|
# ? May 25, 2020 17:32 |
|
BoneMonkey posted:Now I have 3 states, idle, moving and using an ability. Much smoother to have all the moving happening in one action. If I generalized and standardized my vector model, I could easily break it out into configurations instead of hard code. Caliber's is a really rough first pass at it, every node type is hard coded, but I think this model is fantastic for game AI. I think the most important thing I stick to is my bots have no behavior states at all. What I also need to work on is generating meta nodes for more general use. Instead of just paying attention to game objects, there should be some nodes thrown in for stuff like quickly raytraced or just proximity wall detections, and still more complex behaviors off that like a meta node opposite the nearest wall from an enemy to use as cover. Even if I have grid-based randomly generated mazes, I'd generate a meta node on the center of each grid square and have a normal pathfinding algo just sort and weight them and then the vector stacking will lead them along the path while still also reacting to other vectors, and hell it'll even blend them around corners instead of looking like distinct waypointing. Another reason that AI running on player structures is actually a good thing: I think the most important thing for writing good AI is to limit the dataset it's working on. This is also why my bots in Caliber are fake players, because it also gives them the same vision limitations as players. I hate when AI has total information anyway, but also believe it only makes AI even harder to get good behavior out of.
|
# ? May 26, 2020 06:18 |
|
Unity rendering question: let's say I have a procedural world with a big procedural cave in it. None of the lighting can be baked so everything is lit using realtime global illumination. If I'm standing in the cave, the area around me will be properly shadowed (because the terrain above it is casting a shadow) but parts of the cave beyond the shadow distance don't get those shadows so they appear brightly lit. Do I have any options for making that part of the cave shadowed instead of lit? One potential solution would be if I could tell a material "if you're beyond the shadow distance then act like you're unlit rather than fully lit" but I haven't found a way to do that.
|
# ? May 26, 2020 22:12 |
|
|
# ? Apr 26, 2024 20:36 |
|
Triarii posted:Unity rendering question: let's say I have a procedural world with a big procedural cave in it. None of the lighting can be baked so everything is lit using realtime global illumination. If I'm standing in the cave, the area around me will be properly shadowed (because the terrain above it is casting a shadow) but parts of the cave beyond the shadow distance don't get those shadows so they appear brightly lit. What rendering pipeline are you using? You can make specific lights ignore certain objects entirely, but the way to do it depends on the renderer. HDRP has light layers, for instance.
|
# ? May 26, 2020 22:22 |