|
Aneurexorcyst posted:Just giffing it up today... I'd been under the impression your space stations were being overrun with robots as enemies so it's a little jarring to see a cloud of blood in these new gifs! But I'd lean towards "die from X or more damage within the last Y frames => gibs" though, with the simple case of Y as a single frame as probably good enough in most cases. I also saw this video open somewhere in my tabs today that I wanted to (re?)share, since your game looks super clean and quite stylish: https://images-ext-2.discordapp.net/external/fER23ZMtkdxc91N4RVUsFbJJkuoE23LDA5y4qQkNIZY/https/i.imgur.com/FIbDmm9.mp4 (Sound on!) And on the other hand... KillHour posted:No, everyone should explode all the time. Get shot? Explode. Punched? Explode. Stub your toe? Explode. Robot enemies would make extra sense for this too!! 
|
#
?
Nov 5, 2022 23:41
|
|
|
|
| # ? Jun 3, 2024 13:07 |
|
|
https://twitter.com/byobattleship/status/1588935870501228544 Ironically my most successful recent tweet.
|
|
#
?
Nov 6, 2022 01:22
|
|
|
a sinking ship indeed! Also trying to do any graphics stuff myself, even for goofy little projects, makes me appreciate my artist friend doing stuff for our games even more just, staring at aseprite going "what the gently caress does a duck look like??"
|
|
#
?
Nov 6, 2022 01:27
|
|
|
 Again planning out a menu, because I'm a freak and I have to have almost final assets in instead of greyboxing everything. Shoehead fucked around with this message at 15:03 on Nov 7, 2022 |
|
#
?
Nov 6, 2022 23:48
|
|
|
Shoehead posted:
I do this too. I can only stand to look at dev textures for so long, while making and using more finished looking art tends to keep my motivation up. Hell, this is exactly what I'm doing right now, updating a long-time project to have some long needed actual presentation.
|
|
#
?
Nov 7, 2022 01:25
|
|
|
the player's stat display is now working and i've implemented status effects. all (combat) entities can be affected by status effects and will process them independently, so it's a pretty important system even if it isn't terribly exciting to look at
|
|
#
?
Nov 7, 2022 06:26
|
|
|
Shoehead posted:
I'm not really sure why Imgur was being so weird for me last night lol
|
|
#
?
Nov 7, 2022 15:03
|
|
|
Hey everybody, I used to post here a few years ago but fell off the gamedev radar for a while. I started back up a few months ago on a life-sim crafting game and could use some input on UI direction. I originally threw together this UI really quick just to get things working, but I always hated the look of it.  This week though I've been experimenting with a new UI theme based around an old Gameboy kind of aesthetic.  Can't tell if I'm just going down a rabbit hole though, nothing I do seems to make the UI feel right. I like the whole gameboy angle and the shader on the background looks cool, but it's just not clicking in my brain.
|
|
#
?
Nov 7, 2022 17:15
|
|
|
Tummyache posted:This week though I've been experimenting with a new UI theme based around an old Gameboy kind of aesthetic. sup  I've been toying with the GB look too, although I haven't gotten to anything nearly as polished.Not sure the precise feel you're trying to capture but the UI scheme looks pretty sweet from where I'm sitting. It looks pleasant, it's unique, complements the feel of the sprites. The fonts might still need some work (especially the sidebar) but it seems like a great direction.
|
|
#
?
Nov 7, 2022 17:23
|
|
|
Tummyache posted:This week though I've been experimenting with a new UI theme based around an old Gameboy kind of aesthetic. I dunno, I quite like the second option, the shader is very cool. The whole color scheme is also a bit easier on the eyes than the hard contrast of the first. Conveniently, green strains the human eye the least, being right in the perfect wavelength, a faded green even moreso. That pale green is nearly even the same what I color the background on my spritesheets with. I like overall shape of what I see. I'd personally like the smaller numbers a bit larger, but that's just me.
|
|
#
?
Nov 7, 2022 17:28
|
|
|
Thanks for such quick replies! I think I'll move forward in this direction and bump the fonts up to be more readable. I really appreciate it!
|
|
#
?
Nov 7, 2022 17:57
|
|
|
Does anyone have links to research or guides wrt controller accessibility?
|
|
#
?
Nov 7, 2022 18:23
|
|
|
Shoehead posted:I'm not really sure why Imgur was being so weird for me last night lol This looks good except that it stands out that the ABXY buttons are the only thing that looks like you're viewing them from an angle instead of head-on.
|
|
#
?
Nov 7, 2022 18:38
|
|
|
anothergod posted:Does anyone have links to research or guides wrt controller accessibility? https://gameaccessibilityguidelines.com/ is pretty good as a start
|
|
#
?
Nov 7, 2022 19:17
|
|
|
anothergod posted:Does anyone have links to research or guides wrt controller accessibility? Dhamster's link is probably the better all-around resource, but there's also some talks that covered it to various degrees. This one: https://www.youtube.com/watch?v=-XBjj69-uK0 is a general overview on some important considerations. There were also some talks at the IGDA Accessibility conference a couple weeks back that talked about this to various degrees (plus general accessibility). This channel archives them: https://youtube.com/channel/UCKWG26bBd7TOiaLtc_crqvw, and a lot of the talks cover controller accessibility along with adaptive design etc in general. The one on Rocksmith was interesting - albeit not as useful specifically unless your controller is also a guitar - and presented some mechanics, like a practice mode to replay specific sections etc etc that help players adjust to the control scheme. The buddy mode (sic?) thing Xbox has where you can split controls across two input devices was also very cool, although it seems that may be tied specifically to Xbox vOv. I'd actually meant to post about it here earlier, it was v helpful to get such a wide view on the ways games can be more/less accessible, and all the vectors to consider.
|
|
#
?
Nov 7, 2022 19:43
|
|
RIP ZEEZ
|
Trying to remember what I learned about this stuff early on, so I can summarize: - First and foremost, make your controls remappable. This is flatly not optional if you want your game to be accessible. People need to be able to hook up their input system that's optimized for using feet, or a tongue controller, or whatever, and your default control scheme is not going to make sense in those circumstances. - Don't require button mashing, and try to avoid requiring buttons to be held down (adding an option to change held inputs to toggle inputs is valid). Some folks can't easily press multiple buttons at once. - Where possible, "intuit" what the player meant to do and do that, rather than what they specifically input. What this looks like is going to depend on what your game does -- it can be things like adding coyote time to platformers, or forgiving input windows in a fighting game, or snap placement in building games. This doesn't mean "don't make the game challenging", it means "make the game challenging in ways that don't require high levels of precision in inputs".
|
|
#
?
Nov 7, 2022 19:52
|
|
|
Cory Parsnipson posted:I made a hosed up lil' guy! I'm late to the isometric discussion but you've been led to overcomplicate this. A big reason isometric graphics could run on really old platforms is sorting objects is actually pretty simple and doesn't need anything resembling a z buffer. In your case, with your block-based iometric graphics, you already know how to draw the blocks in the right order. The trick, then, is there is no granularity below the block: if an object is spatially inside the block, it's drawn either fully in front or fully behind, depending on a property defined at the block level. Take your stairs block. There is no situation where a character that is on those stairs would be drawn behind them. In the reverse case, with the stairs coming toward the front of the screen, the character would always be behind. With any block where that is ambiguous (say, a fence running through the middle of a block) you either don't permit entry into the block or rework it so it's not ambiguous anymore (move the fence to a back edge of the block so something inside is always in font of everything). If the blocks themselves are drawn in the right order then the corner in front of the stairs is handled naturally because it's actually from a block that's drawn after the stairs and their contents. Chev fucked around with this message at 01:05 on Nov 8, 2022 |
|
#
?
Nov 7, 2022 23:32
|
|
|
Chev posted:I'm late to the isometric discussion but you've been led to overcomplicate this. A big reason isometric graphics could run on really old platforms is sorting objects is actually pretty simple and doesn't need anything resembling a z buffer. In your case, with your block-based iometric graphics, you already know how to draw the blocks in the right order. The trick, then, is there is no granularity below the block: if an object is spatially inside the block, it's drawn either fully in front or fully behind, depending on a property defined at the block level. I'm using the "y-sort" feature in godot's tilemap, which uses the vertical coordinate of both the character and tile origins and puts the lower one on top.  When the character goes above the red square, it gets drawn behind the stairs. What you're saying does make sense, but I'm a bit confused right now at how godot does it vs this other way. ZombieApostate posted:I think you can just treat a character on the stairs as being at the same height level as the floor at the bottom of the stairs and the sorting should work. The floor next to the stairs would be a higher height level and should draw on top. The wall next to the stairs would work like any other wall. I separated the floor tiles and wall tiles into two different tilemaps for the reason above. So if I add stairs to the floor layer, it gets covered by the far wall. Putting the near wall on a higher layer messes up the z-sorting for when the character walks in front of it on the lower floor. I ended up putting the stairs and near-side wall on their own z-level in between the first and second floors with some magic to hide the wall tile when the character is not on the stairs. It's massively overcomplicated though... Fangz posted:Are you letting the character slide along the wall when they collide at an angle into a surface? That might help with the game feel. I copied MMBN where the character just sticks if you run into a wall, since they're hitting it at a 90 degree angle after you take the projection into account. But you did give me an idea to slide the character up or down 1 extra pixel per physics update when they're over the stairs to give them the illusion of going up/down a 45 degree ramp. https://i.imgur.com/nQbW6cO.mp4 The difference is huge! It looks pretty good aside from the fact that the character is on top of the front tile when going down the stairs. I think I can also try and add something where it slides the character if we run into a corner. Gotta figure out how to do that.
|
|
#
?
Nov 8, 2022 01:27
|
|
|
Nice to see a lot of chat and examples of people doing turn-based things as that's my project as well, there's a lot to think about. (Especially since it's a genre where you need to have some idea of a UI just to test things as you're building it.) Right now I'm at the stage where A) the player can attack and deplete the enemy's HP, and B) the player can not only move on their turn, but there's a reset button before you confirm where you've moved so you can decide "no wait not there". The isometric stuff is interesting too, I've seen one tutorial on how to do it in GMS- it's not on my list for this project but it's a possibility for the future.
|
|
#
?
Nov 8, 2022 02:02
|
|
|
https://cdn.discordapp.com/attachments/663197041236901908/1039380330907455568/duckgame.webm wow a duck I'm still in the "awe" stage of getting things to work in GBStudio
|
|
#
?
Nov 8, 2022 08:08
|
|
|
i love the duck with all my heart
|
|
#
?
Nov 8, 2022 08:10
|
|
|
Tummyache posted:Hey everybody, I used to post here a few years ago but fell off the gamedev radar for a while. Overall looks pretty good! Nice and clean. I do have a few general tips though. First, don't feel like you need to have each button be a different color. Less is more. Having too many colors is often distracting and hard to parse on first view. On the topic of parsing though, at first glance I thought the blue boxes (Inventory, Weight, Money) were buttons as well because of their shape and color. I would with either really bring down the saturation or just remove the blue boxes entirely. For the top tabs, try making the selected tab highlighted or distinctive in some way. Without it the UI might feel a little unresponsive and also it creates a better visual hierarchy. With the tab highlighted you could also remove the "Inventory" blue box since it's kind of redundant. I do dig the general Gameboy aesthetic though. Looking forward to seeing where this goes.
|
|
#
?
Nov 8, 2022 08:28
|
|
|
kirbysuperstar posted:wow a duck That's awesome! I'd been meaning to look into GBStudio, how's the ease of working with it?
|
|
#
?
Nov 8, 2022 16:44
|
|
|
GBStudio is neat and it's easier to use than RPG Maker. The most difficult thing is internalizing the graphical limitations of the Game Boy.
|
|
#
?
Nov 8, 2022 17:26
|
|
|
I like working with the wonderswan more than the Gameboy. Multiple 4 shade palettes provides a good look allowing variation in backgrounds while allowing disambiguating foreground and background near/far pointers can suck a toad though
|
|
#
?
Nov 8, 2022 17:29
|
|
|
Joe Desperado posted:On the topic of parsing though, at first glance I thought the blue boxes (Inventory, Weight, Money) were buttons as well because of their shape and color. I would with either really bring down the saturation or just remove the blue boxes entirely. That's what I'm working on now. I'm going to break in a secondary color for general input controls like buttons and text fields, just so they are identifiable, but everything will keep the same saturation level.
|
|
#
?
Nov 8, 2022 21:01
|
|
|
Grace Baiting posted:I'd been under the impression your space stations were being overrun with robots as enemies so it's a little jarring to see a cloud of blood in these new gifs! But I'd lean towards "die from X or more damage within the last Y frames => gibs" though, with the simple case of Y as a single frame as probably good enough in most cases. Oh they're super not robots. They are aliens! Their feet are exposed claws, but other than that they're suited up with face masks - might need to do more than that to sell their alien nature though!
|
|
#
?
Nov 8, 2022 23:20
|
|
|
looking for advice on how to do hit chance calculation i don't like the dnd AC style calculation and i want the hit chance to be determined by the attacker's chance to hit vs. the defender's chance to dodge but i'm unsure on the specifics specifically i'm just trying to steal infra arcana's itemization where weapons have a damage range and a +/- % to hit so the tradeoff when choosing a weapon becomes whether the damage outweighs the hit chance bonus/malus. for example a dagger might have low damage but +20% chance to hit while a sledgehammer has high damage but - 20% chance to hit, and which one is better depends on your traits and the enemy you're fighting. do you have traits that offset the negative hit chance? are you fighting an evasive enemy where you need all the hit chance you can get? etc.
|
|
#
?
Nov 9, 2022 07:51
|
|
|
I go by percentages (essentially "roll under or at" on a d100), but it can get tricky. Part of it is working out just how often you want the player character to hit on average, and working backwards. For example, D&D 4e has its math built in such a way that a PC will hit a monster of their level around 55% of the time, i.e. rolling a 10 or better on a d20, and that to-hit chance comes from multiple sources, their primary attribute, weapon proficiency, etc. So the player still feels they're building a character and can in fact improve on that average quite a bit if they optimize their ability scores or take the right feats or whatever. For video game RPGs I find "misses" are rarer than that, people just kinda don't like whiffing and D&D in all its forms usually keeps it as a higher possibility because, well, tradition. In my project I decided to aim for an average to-hit chance of 80%, but that's factoring in both the player's relevant skill and the defender's evasion (and vice versa.) When I get around to actually displaying to-hit chances I'll also make it display lower than reality, which is a thing the X-Com devs among others do- it compensates for people's biases around probability.
|
|
#
?
Nov 9, 2022 08:02
|
|
|
Dieting Hippo posted:That's awesome! I'd been meaning to look into GBStudio, how's the ease of working with it? Like al-azad said it's not dissimilar from working in RPG Maker, though I think the interface is worse in some ways, like having to go to the Window menu to get to project settings/sprites/audio etc is pretty cumbersome.
|
|
#
?
Nov 9, 2022 09:37
|
|
|
Have reached the stage where the enemy can now do damage to the player, and I've added a graphic that indicates you've been hit. May want to put in something that shows me the numbers so I don't have to run debug mode.
|
|
#
?
Nov 9, 2022 09:52
|
|
|
Recent designs in RPG have made me lean towards “an attack should always do something” even if it’s as basic as missing an attack increasing the probability the next attack will hit. But I’m very much in favor of varying degrees of success rather than failure/success.
|
|
#
?
Nov 9, 2022 14:03
|
|
|
Missing an attack is certainly frustrating. That said maybe there's such a thing as "good frustration". I think there's an issue with hit chances being hard to grok. I think realistically, in the mind of the player, there's only really 4 hit chances - "will definitely hit", "will probably hit", "probably won't hit", and "definitely won't hit". Appreciating what you've done by turning a 75% hit chance to a 85% hit chance is quite intuitively difficult. If I may throw out an idea, maybe it would be good to have hit chances be categorical in this way. You'll just have those four levels of hit-chance, and instead of the knife being a +20% hit, you just upgrade your hit chance to the next step. Further the hit chances won't be evenly spread apart - "will probably hit" will be say, 85% hit, and "probably won't hit" will be 30% hit. Make sure you hand out + and - hit stuff sparingly. You can even use a different calculation when its incoming attacks. For AI attacks on the player, it could be "will probably hit" = 60% hit chance, while "probably won't hit" = 10%. Just to help the player out and make evasion seem extra significant.
|
|
#
?
Nov 9, 2022 14:46
|
|
|
I feel like this was solved in Mario + Rabbids where LOS is either blocked 0%, an enemy has cover 50%, or enemy is out in the open 100%. And attacks rarely just do damage, they push/poison/pull and running into/jumping on enemies is a function so fights are more about positioning than hunkering down. Which in turn increases the effectiveness of moves like overwatch.
|
|
#
?
Nov 9, 2022 14:51
|
|
|
al-azad posted:I feel like this was solved in Mario + Rabbids where LOS is either blocked 0%, an enemy has cover 50%, or enemy is out in the open 100%. And attacks rarely just do damage, they push/poison/pull and running into/jumping on enemies is a function so fights are more about positioning than hunkering down. Which in turn increases the effectiveness of moves like overwatch. Yeah, Mario+Rabbids is a partial implementation of what I'm suggesting, but I think 50% is a bad number. It creates the most variability in long-run results, and I think that has negative consequences. I think it's also hard for players to appreciate what the designer wants them to make of it. You get some common fallacies like players thinking that 2 attacks at 50% hit rate will surely hit at least once, etc. Fangz fucked around with this message at 15:02 on Nov 9, 2022 |
|
#
?
Nov 9, 2022 14:59
|
|
|
Fangz posted:Yeah, Mario+Rabbids is a partial implementation of what I'm suggesting, but I think 50% is a bad number. It creates the most variability in long-run results, and I think that has negative consequences. I think it's also hard for players to appreciate what the designer wants them to make of it. You get some common fallacies like players thinking that 2 attacks at 50% hit rate will surely hit at least once, etc. Rabbids also has destructible terrain, so your 50/50 flip is in many situations still making progress.
|
|
#
?
Nov 9, 2022 15:14
|
|
|
I appreciate the input y'all but I'm just trying to make a simple little traditional roguelike work here, not re-invent turn-based combat  Maxwell Lord posted:I go by percentages (essentially "roll under or at" on a d100), but it can get tricky.
|
|
#
?
Nov 9, 2022 15:24
|
|
|
I'm a fan of auto-hits but wide-range randomized damage, since you retain the uncertainty of "can I hit them hard enough that they can't hit me back" but guarantee you're always making progress towards fight resolution. That style of play does require a pretty big rethink of what the player's defenses are, though. Does armor give you refreshing shields that let you take some damage without taking attrition? Do you just have a ton of fast-refreshing crowd control abilities? Is it all about high mobility as defense? That said, I think how frustrating misses are depends a lot on how fast-paced the game is. They're pretty excruciating in tabletop D&D because maybe it's five minutes until your next turn. They're painful in X-Com because a full turn loop is more like one minute. They're only a little annoying in most roguelikes because turns are instantaneous. 'Wasting' your turn isn't a huge deal in Brogue, except from a strategic perspective.
|
|
#
?
Nov 9, 2022 15:40
|
|
|
Your Computer posted:I appreciate the input y'all but I'm just trying to make a simple little traditional roguelike work here, not re-invent turn-based combat It's also worth thinking about how many hits you want combat to last. Those D&D type numbers tend to either assume you're fighting hordes of lovely goblins or some big beefy monster, and either way the expectation is that getting through the combat will require enough attacks that your hit rolls average out a bit. A 55% basic chance to hit would feel very, very different in a game where each side can only take a couple hits before going down. One thing to keep in mind: if your basic chance to hit is 100% or very close to it, players will be averse to anything with an accuracy penalty and the "meta" (inasmuch as single player games have a metagame) will tend to revolve around making sure those hit numbers stay at 100%, especially if combat is fairly lethal and decisive. If you give players an option between a weapon with 100% accuracy vs. a weapon with 90% accuracy, the lower accuracy weapon might as well not exist for most players unless you give it some pretty big perks.
|
|
#
?
Nov 9, 2022 16:15
|
|
|
|
| # ? Jun 3, 2024 13:07 |
|
|
I've always liked games with luck mitigation/compensation mechanics. Say you're 5% likely to hit but you swing anyway. You miss, but you get 5% (or points) added to the compensation bucket -- say a guaranteed hit+crit at 100%. Meanwhile if you swing with a 95% chance to hit but miss, that'd normally be frustrating. Except you know you get 95%/points added to the compensation bucket.
|
|
#
?
Nov 9, 2022 16:28
|
|
