|
Studio posted:Oh god. smells like fun refactoring times! //what a snipe!
|
#
?
May 12, 2020 23:33
|
|
|
|
| # ? Apr 25, 2024 17:38 |
|
|
Making Games Megathread: smells like fun refactoring times!
|
|
#
?
May 12, 2020 23:52
|
|
|
Popoto posted:smells like fun refactoring times!
|
|
#
?
May 13, 2020 00:06
|
|
|
TooMuchAbstraction posted:I got to watch someone play my game via Twitch, and one of the big issues they ran into was a failure to communicate why your guns can't shoot at a target. Consider this situation: That way as the player changes weapon group they see something change on screen go "what's that?" see the firing arc and as they switch between all the different groups can visually see each ones arc for those few secs and burn it into their memory. Of course have it disable-able for pro strat players who know their ships like they know their MMO mouse. Also congrats on having a twitch steamer play your game! That's way cool!
|
|
#
?
May 13, 2020 00:21
|
|
|
kaffo posted:First thing that comes to my mind is to draw the firing arc for every weapon in the selected weapon group as you select it for about 3 or 5 seconds then fade it away. quote:Also congrats on having a twitch steamer play your game! That's way cool! Hahaha, thanks. It was fellow goon madjackmcmad, I asked him to play the game during his routine dev livestream and he was amenable. Total audience of maybe 20 people, but hey, I got like a bug a minute from watching him so it's all good. 
|
|
#
?
May 13, 2020 00:41
|
|
|
I was gonna suggest something similar but have it drawn underneath the ship and maybe consider only drawing it when the selected weapon fails to fire.
|
|
#
?
May 13, 2020 00:42
|
|
|
Alternatively, depending on whether ammo is a big concern or not, just fire the weapons anyway. It might be a touch more intuitive to see at least something happen, and this way at least it's obvious that they're firing (just not on target) rather than not firing for ??? reasons.
|
|
#
?
May 13, 2020 00:48
|
|
|
Gonna +1 on 'active group arcs' overlay, because it will also help when one switches to some new target in a wildly different direction and has to quickly determine what group is aimed that way. I think this leans into your center of screen guidance as well, because the 'correct' group will be pointing forward and more central. I haven't played it yet though. I don't know how complex these groupings are, or whether all weapons of a group must overlap, or if that group is player-configured.
|
|
#
?
May 13, 2020 00:56
|
|
|
So, the approach that I'm leaning towards at the moment is the "one reticle per gun" approach. A very quick mockup: The red crosses would need to overlap with the red circle for the gun to be able to fire; that could be accompanied by a chirp or click or other sound effect. Crosshairs could also have different shapes/colors to indicate...something The arcs overlay would look something very roughly like this:  That's a pretty simple case; more extreme would be the guns which would look like this:  And that's not all that many guns; I've made ships with more than twice as many. So I'd want to solve that drawing issue if I'm going to go with drawing arcs.
|
|
#
?
May 13, 2020 01:36
|
|
|
TooMuchAbstraction posted:So, the approach that I'm leaning towards at the moment is the "one reticle per gun" approach. I agree with this decision. An added benefit is that you can have different guns with different tracking speeds, and the player can choose to fire a limited salvo early, or wait for all of their guns to align on target.
|
|
#
?
May 13, 2020 02:01
|
|
|
I'm doing the "one reticle per gun" approach for my space game, though the control scheme for it is much more hands-on; it's equal parts "what angles can you fire from" and "where exactly are you aiming". I'd like eventually for the equipment screen to show the full arcs of each hardpoint, but I'm a fair bit from that. So far it seems to give the best balance of information and reduced screen clutter.
|
|
#
?
May 13, 2020 02:21
|
|
|
I'm gonna give this a try tomorrow, I've always wanted to make a game like that, but last time I gave it a go, I ended up spending all of my time making an insanely complex ballistics physics compute shader, then I got a new job so I didn't have time to mess with it anymore. E: It occurred to me that if you are controlling the aim, some of the problems I mentioned would be really obvious to the player. So you can probably ignore it. The reticle idea is pretty intuitive. Putting an X in the middle of the ones that can't fire would make it really obvious. In addition, some 2D hud indicator, like a little line or something, that makes it clear that the gun can't train over any further, and that's why it's not firing, versus the target being out of range or something else. Something to note about the reticle is that the gun would have to aim ahead of the target to hit it. If the reticle follows the line to the target, and the target is quickly transversing your own ship (let's say, an aircraft cutting across your bow), then the gun could be at its cutout or train limit (and unable to fire given the solution), but the reticle would still overlay the target, which would be kinda confusing. Like I mentioned before though, I get a bit obsessive over these things, and you might just want to fudge it in that case for the sake of fun. So you might want to have the reticle indicate the line to the firing solution, the downside being that some people might not realize that they are actually correctly aimed right away. Another solution might be to display an elliptical area of uncertainty for the point of impact for each gun. I'm not exactly sure how you would implement it though. Drawing circles all over would probably obscure all the cool ship and airplane models. It's an option though. I think drawing 3D cutout arcs at the mount would be really confusing due to parallax. It also has the aforementioned downside of covering up your cool ship. Perhaps you could draw the cutouts in the minimap. The only caveat is that indicating the static range of the weapon would be misleading. Consider an enemy ship closing on your own ship at a high rate: if you want your torpedo to intercept it at max range, you would have to fire the torpedo while the enemy ship is still well outside that range. I've got way more  , and I'll have to wait until tomorrow to try it out, so I'll just send you a pm.
dougdrums fucked around with this message at 03:00 on May 13, 2020 |
|
#
?
May 13, 2020 02:45
|
|
|
Thanks for the thoughts! I realized I need to clarify a couple of things. I keep forgetting that not everyone has an exhaustive knowledge of how my game works. When you're locked onto an enemy, all aiming is automatic. Your guns take care of doing ballistics calculations (or other calculations as appropriate to the weapon type) and take account of travel time, and will fire at where the target will be, not where it is. They have some innate inaccuracy but you're just stuck with that, unless you install fire control systems to reduce it. You can do manual aiming (just don't lock onto anything and the guns will try to track the center reticle); in that case you're responsible for choosing where to aim at and your guns will handle the calculations to hit that point. If your target has moved on by the time the shots arrive, that's on you. Ships can have a lot of guns, and gameplay is very fast-paced compared to most naval combat games. The trailer I made is months out of date but should give some idea of the speed of combat. My intuition is that I need a system that prioritizes being able to be read quickly over a system that provides maximum details. Of course if both are attainable that's great. dougdrums posted:The reticle idea is pretty intuitive. Putting an X in the middle of the ones that can't fire would make it really obvious. In addition, some 2D hud indicator, like a little line or something, that makes it clear that the gun can't train over any further, and that's why it's not firing, versus the target being out of range or something else. The range-to-target indicator is red if the target is out of range. I would definitely want to shape the reticle to give some indication. At the moment I imagine shapes/colors for "target is in my arc but I haven't traversed to it yet", "target is outside of my arc", "I am currently reloading", and "I am ready to fire". A modification of the "target is outside my arc" that indicates that the gun is at the limit of its range of motion could also make sense. Iconography is hard though.
|
|
#
?
May 13, 2020 03:20
|
|
|
it depends a lot on how exactly your aiming/target-lock system works, but it'll need to be a combination of showing the arc, and tracing a vector so they can see where they are currently aiming in relation to that arc, so they can see how they'd need to turn to get into the arc. as a player of your game, I want an indicator of what I have to do next to bring my guns to bear, and I want that indicator to be where I'm looking while I aim. maybe a moving arrow left or right, like the way highway construction signs are? "turn the ship this way to shoot him with the guns you've picked"
|
|
#
?
May 13, 2020 03:43
|
|
|
LordSaturn posted:it depends a lot on how exactly your aiming/target-lock system works, but it'll need to be a combination of showing the arc, and tracing a vector so they can see where they are currently aiming in relation to that arc, so they can see how they'd need to turn to get into the arc. as a player of your game, I want an indicator of what I have to do next to bring my guns to bear, and I want that indicator to be where I'm looking while I aim. maybe a moving arrow left or right, like the way highway construction signs are? "turn the ship this way to shoot him with the guns you've picked" I agree that the player wants clear, actionable input. I like the idea of putting arrows around the reticle. The big challenge I feel is that the player can have so many different firing arcs "active" at one time. Like, they don't select their starboard torpedo launchers to fire, they select all of their torpedo launchers to fire. Some of them are just not going to be relevant for the given target because they're facing close to 180 degrees to it. It wouldn't make much sense to have a UI indicator saying basically "turn around and you can fire your port-side torpedo launchers instead of the starboard ones!" I think there's a good reason why I haven't tackled this problem before now...
|
|
#
?
May 13, 2020 04:03
|
|
|
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 play now in your browser, on kongregate, or don't also if you have a kong account and are capable of rating games, I want you to know, we don't talk much but I always thought you were cool
|
|
#
?
May 13, 2020 06:16
|
|
|
TooMuchAbstraction posted:I agree that the player wants clear, actionable input. I like the idea of putting arrows around the reticle. The big challenge I feel is that the player can have so many different firing arcs "active" at one time. Like, they don't select their starboard torpedo launchers to fire, they select all of their torpedo launchers to fire. Some of them are just not going to be relevant for the given target because they're facing close to 180 degrees to it. It wouldn't make much sense to have a UI indicator saying basically "turn around and you can fire your port-side torpedo launchers instead of the starboard ones!" On your last note there, you could genuinely have a status box in the corner of the screen with some flashy text (or a scale model of the ship with flashy guns) going "X CANNOT FIRE DUE TO Y" which updates. Like a debug log for players
|
|
#
?
May 13, 2020 09:07
|
|
|
I was working on a practice thingie that looked pretty decent in Blender, but looked like total butt once I got it into Unity and added some color:  Am I correct that texturing is the biggest thing contributing to the colorized version looking meh? My eyeballs say it's the geometry, but urban scenes are like 90% straight lines and I've seen tons of decently high-res games with sharp-edged, rectangle-y buildings that look great.
|
|
#
?
May 13, 2020 09:15
|
|
|
Content for the content mines: I've never actually shown off any screenshots of the stuff I'm doing here before, so here's something that I find kind of neat. The game I'm making is intended to be somewhere between Freelancer and EVE. So in the finest traditions of Freelancer, Digital Anvil, and being a programmer first and an artist seventh, I put together a handful of prefabs that let me slap together space stations of all shapes and sizes really quickly. Pictured below is a quick test for a station that took me about two minutes to throw together from five distinct parts (destroyer-sized docking bay, cross structure, six-way connector module, three-way connector module with windows, and a two-way connector module with windows). A component on the parent object for the station automatically detects the docking bays and any additional docking points that have been manually specified and what sizes of ship they're capable of handling, setting up the entity info so it exists in world space as a defined entity, and once there's more game in place, it'll be able to be docked with, players will be able to interact with things like personal and fleet storage, markets, equipment fabricators, et cetera, all based on how the station is defined both in its static station entity settings and what it's defined as in the world database. I'm thinking of doing something to procedurally generate some station layouts as well, because right now they're all hand-placed. Solar systems are all composed of several Unity scenes, with one for each playable region (since the generally accepted limit of what Unity is capable of handling in its physics and rendering engine is around +/- 9000 units at the sub-millimetre level of accuracy, everything is scaled down by 100, giving roughly 5 cm of accuracy at almost 2000x2000x2000 km of world space, which is probably an order of magnitude more than I need). More importantly though I need to develop a tool for defining the overall layout of a solar system and then an editor script to generate all of the scenes and the world objects needed to make them work from the tool's output. So, yeah. Space!  e: Heck, while I'm at it, some UI stuff I was working on recently. Every entity that does or can exist in the world can have an entity info window spawned for it; this is what it looks like currently for a pair of prototype-grade (I guess the MMO equivalent would sorta be like blue drops, except they're not strictly mechanically better than generic or faction equipment) pieces of equipment. 
Kazinsal fucked around with this message at 09:24 on May 13, 2020 |
|
#
?
May 13, 2020 09:19
|
|
|
TooMuchAbstraction posted:You're probably going to want to have some central component that handles combat logic. You tell it, "hey, actor 1 is attacking actor 2 using melee" and it looks at their stats, does all the math, and assigns damage accordingly. You definitely don't want to distribute all the logic of giving and taking damage across your codebase. Yeah, this tends to be best approach. I basically make exclusively turn-based games, and what I normally do is have a central stateful object. It serves two purposes: perform all the combat logic/calculations and host all the co-routines gameobjects. The game objects themselves basically just host combat data (e.g., HP, useable skills, etc) and a bunch of functions that run animations/audio. That say in a traditional "life-drain" attack, my combat manager object can calculate whether the attack hit or not, how much damage it did, how much did it heal, and whether or not that is the final enemy it died and so combat is over. then queue up a series of coroutines that are resolved in order to: Play the attack animation, show damage numbers, play damage animation, show damage numbers, and potentially play the game over animation. Since the the actual co-routine logic lies on the individual game objects, it's pretty easy to resolve them in such a way that looks clean (like returning the attack animation co-routine as soon as the attack animation "connects", rather than after the backswing of the animation finishes so there isn't a weird lag time between the attack hitting and the damage numbers popping up). Turn-based games by their nature are very stale in presentation, so these kinds of approaches make them a lot more JUICY which in my experience tends to make or break a turn-based game's marketability.
|
|
#
?
May 13, 2020 13:51
|
|
|
Omi no Kami posted:Am I correct that texturing is the biggest thing contributing to the colorized version looking meh? My eyeballs say it's the geometry, but urban scenes are like 90% straight lines and I've seen tons of decently high-res games with sharp-edged, rectangle-y buildings that look great. it cannot be overstated how much work the textures do in most games. Even if you aren't painting in things like shadows and reflections, it's still the job of the texture to have..... texture. Your surfaces are all very clean and uniform, there's no grime or dirt or scuffs or anything to break up the tiling textures. Corners have wear and tear. Dust accumulates in nooks and crannies. Also, if you aren't painting in light/shadow details by hand and want to rely on the lighting and post-processing to do most of the work you need to give it more to work with, namely normal maps that break up the clean surfaces. One thing to keep in mind if your eyeballs want to blame the geometry is that a lot of old games still look stunning to this day despite having extremely low polygon counts and no realtime lighting or post-processing, simply by having good textures.
|
|
#
?
May 13, 2020 14:26
|
|
|
Your Computer posted:100% Awesome, thanks for the feedback!  For texturing itself, assuming I'm going for the handpainted silent hill/WoW classic look am I right that the best use of study time is grinding pencil sketches until I can render and detail still lifes/texture studies at the approximate level of detail and style I want, then transition that style to digital? I've been constantly surprised at the lack of texturing-specific textbooks and resources, so I assume most artists are getting that background from somewhere else.
|
|
#
?
May 13, 2020 14:46
|
|
|
Omi no Kami posted:Awesome, thanks for the feedback! If you're wanting to go for a handpainted texture style, there are quite a lot of online tutorials of varying quality out there(This one by Tyson Murphy looks good, he knows his poo poo), but if I was you I wouldn't bother with pencil drawing - you want to learn to paint, and you might as well learn to do that digitally.
|
|
#
?
May 13, 2020 15:10
|
|
|
I can tell you straight up there’s nothing hand painted about Silent Hill except maybe touch ups and smaller bespoke details. It’s all photo manipulation and renders of cinematic models. WoW is hand painted but good luck getting anything done as a single artist on that scale.
|
|
#
?
May 13, 2020 15:26
|
|
|
Omi no Kami posted:I was working on a practice thingie that looked pretty decent in Blender, but looked like total butt once I got it into Unity and added some color: It's the lighting. Edit: More specifically, it's the way your lighting interacts (or doesn't, really) with your materials. Ambient occlusion would help a lot. Are you baking your lighting? You should. KillHour fucked around with this message at 15:38 on May 13, 2020 |
|
#
?
May 13, 2020 15:35
|
|
|
al-azad posted:I can tell you straight up there’s nothing hand painted about Silent Hill except maybe touch ups and smaller bespoke details. It’s all photo manipulation and renders of cinematic models. Yeah but at PS1-era level of resolution it's not that particularly noticeable.
|
|
#
?
May 13, 2020 15:39
|
|
|
KillHour posted:It's the lighting. I'd argue that lighting is more important than textures. Yes texture work is a big deal, but with a quality light setup (including the shaders) you can really blow people's minds. My favorite example of this is what shaders (and more recently, ray tracing) can do for Minecraft.
|
|
#
?
May 13, 2020 15:42
|
|
|
Omi no Kami posted:Awesome, thanks for the feedback!  I've never been that good at painting by hand, but if you're going for a more realistic approach a much easier way is actually just mashing things together in photoshop. This isn't something you would want to do for a completely handpainted style like WoW but would be very in line with how they did stuff for Silent Hill and similar games of that era. You'd be surprised at how much of the texturework on more realistic-leaning games are basically just photoshops upon photoshops, cutting and pasting parts of different photos together to get the right "feel". Of course, photo manipulation is a skill of its own but you can be a lot more sloppy and still have it come out looking great unless you're targeting very large texture resolutions v vthis is probably not the best example since I threw it together in a hurry, but I tried showing the general idea of what I'm talking about   base texture on the left and photoshopped texture on the right, just taking bits and pieces from other photos and cutting, pasting and retouching that also brings me to another very important point - the texture no longer tiles. Tiling is always a tradeoff - obviously it's a lot easier to texture with, but our brains are incredibly good at picking up patterns so tiling textures always stand out like a sore thumb. There are several ways people have used to get around this; - Having a tiling base texture and then painting individual variations on the base texture that all tile neatly together - Same as the above, but blending multiple tiling textures together with texture blending - Breaking up the monotony by judiciously utilizing vertex colors (Nintendo were doing this a ton all the way up to the Wii U era) - Making sure that you never tile the same texture over a large surface and visually interrupt it with other geometry or textures - Use tiling textures but have another layer of decals on top with things that mask the tiling (think pipes, posters, stains, that sort of thing) In an ideal world you would be unwrapping and texturing each surface individually and never using a tiling texture, but that's an inhuman amount of work and a nightmare to keep consistent so you always gotta find a tradeoff. e: also I'm going to disagree with the the statement about the lighting even if the lighting was the most computationally expensive, realistic and dynamic it still wouldn't mask the bland and tiling textures. This here is one of the major problem spots:  there is nothing to break it up, no wear and tear, no variation around the corners. A good texture will mask how simple the geometry is, but here the textures only serve to point out how flat everything is. Lighting won't change that because the lighting doesn't have anything to work on. Your Computer fucked around with this message at 15:58 on May 13, 2020 |
|
#
?
May 13, 2020 15:45
|
|
|
SweetBro posted:Yeah but at PS1-era level of resolution it's not that particularly noticeable. I was inferring the PS2 and later games but even in the 90s photo manipulation was the way to go for “realistic” textures.
|
|
#
?
May 13, 2020 16:04
|
|
|
TooMuchAbstraction posted:I agree that the player wants clear, actionable input. I like the idea of putting arrows around the reticle. The big challenge I feel is that the player can have so many different firing arcs "active" at one time. Like, they don't select their starboard torpedo launchers to fire, they select all of their torpedo launchers to fire. Some of them are just not going to be relevant for the given target because they're facing close to 180 degrees to it. It wouldn't make much sense to have a UI indicator saying basically "turn around and you can fire your port-side torpedo launchers instead of the starboard ones!" if you can find a way to calculate "how far outside of this arc am I" then you can pretty easily compute "what arc am I closest to being in" and then just show guidance to reach that arc. if a player really wants to serpentine back and forth to dump alternating torpedos on the target, they're probably not looking at your guidance arrows that said if we've just settled on "show them which way to turn to get inside of the nearest arc for their selected weapon" then the on-ship display can just be "here's the arc I'm talking about, and here's your direction of aim". maybe some smaller indicator i.e. a green/red dot for "here's all the mounts of this weapon, due to angle these ones can fire and these ones can't" you can also put up-arrows underneath the reticle for "you need to be closer to hit them with this"
|
|
#
?
May 13, 2020 16:20
|
|
|
Your Computer posted:e: also I'm going to disagree with the the statement about the lighting This is what I clarified with my edit - the materials don't do anything to interact with the lighting. There's a barely noticeable bumpmap on a completely flat surface.
|
|
#
?
May 13, 2020 16:25
|
|
|
kaffo posted:Like a debug log for players Players don't read words. I mean that in all painful seriousness.
|
|
#
?
May 13, 2020 16:33
|
|
|
KillHour posted:It's the lighting.
|
|
#
?
May 13, 2020 16:47
|
|
|
Unreal Engine 5 announced. Available in 2021. UE4 devs will be able to easily transition. https://www.theverge.com/2020/5/13/21256079/epic-unreal-engine-5-playstation-5-demo-next-gen-graphics-release-date Also announced: They will now only start taking 5% after the first $1million in sales and that change is retroactive to the start of this year.
|
|
#
?
May 13, 2020 16:52
|
|
|
Hammer Bro. posted:Players don't read words. Players only read words when something happened that they don't understand which pissed them off and they're trying to figure out how they just dicked over.
|
|
#
?
May 13, 2020 17:27
|
|
|
Omi no Kami posted:I was working on a practice thingie that looked pretty decent in Blender, but looked like total butt once I got it into Unity and added some color: Not a mean joke-- have you considered an isometric camera? That kind of "diorama" presentation that a lot of PS1 era games used is well paired with the low fidelity of your assets. This screenshot comparison demonstrates pretty starkly how bringing the camera down to eye level makes everything far more challenging, which I am not necessarily trying to discourage if that's your dream, but considering you seem to be doing all the art yourself while learning everything from scratch, having limitations is not always a bad thing. As for the scene itself, it's hard to say whether the lighting or texture work is the biggest issue, though it seems clear that both need work as people have discussed. The lighting in particular lacks any kind of cohesion and feels very synthetic, I couldn't even begin to guess what time of day it is in this scene.
|
|
#
?
May 13, 2020 17:38
|
|
|
Observational stuff regarding texturing and environment details that I try to apply to my own work: Low texture detail? hide it with clutter.  Be "lazy" like Nintendo. Don't create two textures when you can just rotate and mirror your UVs. And unless you're working with low-res pixel art don't worry about perfect texture alignment. Look at the bricks on the pier: the textures don't align at all.  Use masks and vertex painting. This screenshot is literally two 32x32 textures, one for the wall and one for the floor. The mesh is then painted to give gradation to the texture. This is why Rare's N64 games looked better than everyone else.  Contrast! John Romero's personal rules for creating Doom maps focused on contrasting between texture changes. Want to change the floor texture? Change the floor height. Doors should be built into a different texture from the wall. When changing a wall texture, split them with a smaller texture as a transition.  IMO I think studying Doom textures is a requirement because it's amazing what they worked with in 1993. Basically all "flats" (ceiling/floor) are 64x64 and all walls are 64x128 with some exceptions. In general the textures are meant to stand alone but the alignment can be adjusted manually to isolate parts of the texture. For example a wall might have a 16 pixel high concrete portion on the bottom: innocuous on its own when you're viewing the full texture but isolate it and you create stairs or a small platform without having to create a brand new texture.  Silent Hill games are masterful about contrast. The ground here has the UVs offset to create a unique pattern from a single texture. The building is broken up into three sections: the walls with the windows, the door splitting them so you notice the tiling less, and the upper portion which has two variations of the pattern but flip that UV and you turn 2 textures into 4. Mirror it and it becomes 8! al-azad fucked around with this message at 18:04 on May 13, 2020 |
|
#
?
May 13, 2020 18:01
|
|
|
xgalaxy posted:Unreal Engine 5 announced. Available in 2021. https://www.youtube.com/watch?v=qC5KtatMcUw They're also releasing their online services for free.
|
|
#
?
May 13, 2020 18:04
|
|
|
al-azad posted:Observational stuff regarding texturing and environment details that I try to apply to my own work: It's criminal do make a post like that and not mention team fortress 2. 
|
|
#
?
May 13, 2020 18:06
|
|
|
|
| # ? Apr 25, 2024 17:38 |
|
|
Omi no Kami posted:I was working on a practice thingie that looked pretty decent in Blender, but looked like total butt once I got it into Unity and added some color: Not that textures and lighting aren't important but I think another thing to keep in mind is that there just isn't a whole lot going on at the ground level of this scene. Sure the upper floors have windows and signs as well pipes and stuff on the roof but I would say you should focus on having most of the detail at eye level for the player. Right now it's just a couple of barren walls and some doors. You could easily spice it up by throwing in a few more windows or just slapping some posters or graffiti on there to fill in the empty space. Props would definitely help too, like some trash cans or mailboxes.
|
|
#
?
May 13, 2020 18:11
|
|
