|
Yeah, definitely agreed with the people saying "pick a simple aesthetic and figure out how to make it look good". The average game needs a lot of art, so anything you can do to make each individual piece take less effort is good. That includes reducing or eliminating textures and animation, using pixelated or low-poly styles, letting automated stuff (postprocessing, lighting, fog, etc.) do a lot of heavy lifting for you, and on and on. Like, here's a screenshot I took this morning: https://twitter.com/byobattleship/status/1388202781530419201 I managed to hang Unity by trying to select a few hundred particle systems during Play mode, so my attempt to show a less dressed-up version of the same shot is going to be me taking a screenshot of the game in the editor with some stuff still hanging around, but here's the same shot with all postprocessing turned off and most explosions (which are from asset packs I bought off the asset store) disabled:  Practically all of my models are totally untextured; I just assign materials on a per-face basis, and I have around 20-30 very similar materials to choose from. Effectively the material becomes a color and I do paint-by-numbers. But by adding a fair amount of postprocessing, especially a) color grading, and b) a fairly fancy skybox fog system, a lot of that simplicity gets hidden unless you look closely. It took me a long time and a lot of iterations to end up at this aesthetic, but I knew from the start that I'd need a lot of 3D models and couldn't afford the time to make good models. So I just made my crappy models and took it on faith that eventually I'd figure out how to make them look decent-ish.
|
#
?
Apr 30, 2021 21:43
|
|
|
|
| # ? Jun 3, 2024 13:39 |
|
|
CodfishCartographer posted:Quick question: What's the best way to handle things when you need multiple layers on a single object in Unity? Obviously you can't, but I'm curious what workarounds people have done. Just use Tags instead? Wish you could use tags as a layermask lol. If there's only a few overlaps you can just create a layer that's "A+B" and have it be treated appropriately, but that can be prohibitively complicated if you have lots of overlaps. TooMuchAbstraction posted:Like, here's a screenshot I took this morning: https://www.youtube.com/watch?v=rcYhYO02f98
|
|
#
?
Apr 30, 2021 21:49
|
|
|
So I'm trying to implement a thing where you can grab enemies and hold them up as shields. I have it MOSTLY working, but I'm having troubles getting them positioned + rotated correctly. I have a game object parented to the player camera to be the reference point for where held enemies should be located. Then when I grab enemies, I set their parent to the reference location (holdLoc), and then set their position and rotation as well:code:And while this DOES move and rotate the enemy, it doesn't move and rotate them to the exact position of the holdLoc. If I'm standing in front of the enemy it's close enough to appear correct, but if I'm standing above/below the enemy then they keep roughly the same distance away. Here's a short clip to show what I mean: https://imgur.com/8ZK3Nh9.mp4 I've tried different combinations of using localPosition/localRotation but that doesn't seem to do the trick either. Not sure where I'm going wrong here?
|
|
#
?
May 1, 2021 00:02
|
|
|
Hmmmm. Can you render a cube to that holdLoc position to make sure its actually where it should be the whole time? I guess you can see in the editor where the position is without having it render it. In theory what you're doing seems right. The object doesn't have any code moving it does it? But it seems like its otherwise staying in place where it should be... Zaphod42 fucked around with this message at 00:26 on May 1, 2021 |
|
#
?
May 1, 2021 00:22
|
|
|
I'm not entirely clear on how things are set up. Could you provide a screenshot of your scene hierarchy when an enemy has been grabbed? Two things that occur to me, though: - The origin of the enemy model might not be where you expect it to be - You should set localPosition to Vector3.zero and localRotation to Quaternion.identity, instead of setting position/rotation to match the parent. It should do the same thing...but maybe not, I've had issues sometimes with weird transforms when setting parents.
|
|
#
?
May 1, 2021 00:27
|
|
|
Zaphod42 posted:Hmmmm. Ah hah! This post helped me figure it out. I added a cube mesh renderer to holdLoc to double check the rotation and stuff was correct, and yup it looked fine. The only thing that controls enemy movement is their nav mesh agent, which is disabled when the enemy is grabbed. HOWEVER! The function that checks if the enemy is grabbed to disable the agent is ran in Update, and my best guess is that it was running just after the enemy is actually grabbed. I added a call to that function in the grab code to ensure it disables the nav mesh agent at the proper time, and that seems to have fixed it. TooMuchAbstraction posted:I'm not entirely clear on how things are set up. Could you provide a screenshot of your scene hierarchy when an enemy has been grabbed? I also changed the positioning like you suggested, and it properly positions with the changes I made above. Thanks for the help from both of you!
|
|
#
?
May 1, 2021 00:52
|
|
|
CodfishCartographer posted:I'll have to check it out! The idea was inspired by the PS1 game Threads of Fate, which had a similar concept for casting spells - you chose an element, and then a way for that element to be shot such as "spread", "explosive", etc. Of course, Gunstar Heroes is an old console game, so all the weapon combos are pre-made rather than procedural like your system. But still, it would be interesting to have a system where each element has a set of 'base' behaviors (rate of fire, spread, penetration, bullet speed, homing) and combinations of crystals would blend/mutate according to a set of rules to get the final spell/weapon. Sorry if I'm getting ahead of myself, I just saw modular spellcasting and Gunstar Heroes mentioned in quick succession and lighting struck my brain and set my neurons on fire.
|
|
#
?
May 1, 2021 05:08
|
|
|
Tupperwarez posted:Seconding to check out Gunstar Heroes' weapon combination system. What I find neat about that system is that each 'element' has a key feature that is expressed/represented in some way in each of the combinations. Even doubling up on an element results in an exaggerated version of the base element. Design-wise I'm more or less going for a similar thing - each weapon has an overall theme, and each element has an overall theme, and they combine together. Pistol tends to be low damage but easy to aim, fire element tends to be high damage but low range - so fire pistol is moderate damage that requires little aim, but low range (in the case of fire pistol, a constant spread of projectiles)
|
|
#
?
May 1, 2021 05:57
|
|
|
Zaphod42 posted:You can make 3D games without going high detail if you make some clever choices, lean into style, or use lots of shader effects. Low-poly is kinda "in" right now, if anything, which makes it easier to target a consistent aesthetic. If you look at a game like Doom, its not detailed but it does at least look consistent, which I think is more important. So targeting a lo-fi but consistent look can be a great way to go. Yes, I agree. Just the amount of work involved to even getting a very bare bones ugly 2-plane wall/floor combo was a bit more annoying than I had hoped it would be. And the end result helped me to think that I could crank out some better sprites or something than I could even super basic 3D levels. 2.5D for me is like where there is basically billboards as sprites and the floor is sort of 3D so it has perspective and no need to try to code parallax and you get that because of the 3D part. Though I'm all over the board now really. Looking at godot pretty hard over Unity because I am bouncing hard on Unity's UI after the very nicely done UI I learned with Unreal. Plus it seems like everything is a weird plug-in rather than something integrated and this black box magic approach doesn't feel quite right. So naturally I've been researching all the "engine A vs engine B" stuff and it's all over the board as expected 
|
|
#
?
May 2, 2021 02:46
|
|
|
The Titanic posted:Looking at godot pretty hard over Unity because I am bouncing hard on Unity's UI after the very nicely done UI I learned with Unreal. I'm super enjoying Godot personally. The whole scene tree organization, everything GUI thing also being accessible via code, and the observer pattern for communicating between nodes just clicks well in my brain.
|
|
#
?
May 2, 2021 02:53
|
|
|
cmdrk posted:I'm super enjoying Godot personally. The whole scene tree organization, everything GUI thing also being accessible via code, and the observer pattern for communicating between nodes just clicks well in my brain. I've downloaded and installed it. I'm probably going to have to play with it at this point.  Do you (or somebody else) happen to have any knowledge about sprite performance and what a good resolution for art assets could be? Part of me wants to do sprite, and another part just wants to go bigger with more conventional drawn art, but not using the spine system, so it'd be framed animations. I'm not sure how big I could/should make any of that stuff.
|
|
#
?
May 2, 2021 03:05
|
|
|
Baby’s first Screenshot Saturday https://twitter.com/dupersaurus/status/1388602465373855746?s=21 Now to make a weather system  oh and I guess a game at some point???
|
|
#
?
May 2, 2021 03:12
|
|
|
dupersaurus posted:Baby’s first Screenshot Saturday I'd buy it
|
|
#
?
May 2, 2021 03:32
|
|
|
The Titanic posted:Do you (or somebody else) happen to have any knowledge about sprite performance and what a good resolution for art assets could be? Rule one of performance is "don't worry about it until it becomes a problem". What causes performance issues is often hard to predict, and best solved with a profiler. And unless you're targeting a platform with limited capabilities, your performance issues are far more likely to be caused by poor algorithms than by inefficient graphics. Having said that, there's not usually any point in having art assets that have higher resolution than what your target resolution can display.
|
|
#
?
May 2, 2021 03:35
|
|
|
TooMuchAbstraction posted:Rule one of performance is "don't worry about it until it becomes a problem". What causes performance issues is often hard to predict, and best solved with a profiler. And unless you're targeting a platform with limited capabilities, your performance issues are far more likely to be caused by poor algorithms than by inefficient graphics. Any good resources on, uh, how to read the profiler? The FPS section is somewhat easy to understand but everything else is totally baffling to me.
|
|
#
?
May 2, 2021 03:53
|
|
|
CodfishCartographer posted:Any good resources on, uh, how to read the profiler? The FPS section is somewhat easy to understand but everything else is totally baffling to me. I can tell you how to read Unity's profiler! First, make sure "Deep profile" is enabled. With deep profiling disabled, you get a stochastic overview of your performance. This is cheap to collect but inaccurate. With deep profiling enabled, you get a much more rigorous analysis of exactly how much time you spend in every single function. The downside is that deep profiling is much more expensive, so your performance in-game is worse. But you don't generally need to deep profile for very long, so who cares? Here's some deep profiling output from my game:  Up at the top, you get a graph showing CPU use, broken down by broad categories. I find this is mostly useful for finding frames that are particularly slow. In the middle is time spent rendering, and the bottom graph (in my view, you can rearrange these) is memory. I mostly don't worry about those so much. What I really care about is the table at the bottom. Note that I have it in hierarchy mode.  Unity defaults to "timeline" mode which is as far as I can tell completely impossible to read. Hierarchy mode makes way more sense (for me, anyway). It gives you a breakdown of time spent in each function in the current frame. Note that Unity doesn't aggregate profiling data across frames, so far as I'm aware. Still, looking at one frame at a time still gives you a lot of useful information. The columns (which you can click on to sort the table) are: - Overview: the name of the function call - Total: the percentage of CPU time spent in this function, or in functions that that function calls, etc. - Self: the percentage of time spent specifically in this function (and not in anything it called) - Calls: how many times this function was invoked - GC Alloc: how much memory this function or its children allocated - Time ms / Self ms: as "Total" and "Self" but in milliseconds instead of percentage. These numbers are semi-meaningless due to the overhead of doing deep profiling, but they can be easier to compare than the percentages of the "Total" and "Self" columns. You can ignore the "EditorLoop" entry. That's time spent by the Unity editor doing editor things; it has no effect on performance. This frame took ~58ms overall. 18ms were in FixedUpdate, which ran 12 times, and 14ms were in regular Update, which ran once. Multiple FixedUpdates per regular Update is common when your system is struggling to keep up and you have a high target physics framerate (mine is 60FPS). What I'd like to know is why my regular Update call allocated 1.6kB of memory. So I sort by the "GC Alloc" table and then open up entries until I end up with something like this:  Basically I keep opening up entries that have high GC Alloc values until I find a function that I recognize as a culprit. In this case, one of the allocations is due to String.Format -- I'm paying 800 bytes per frame to generate a new string, every frame. That's because the SurviveTimer class draws a "Survive for MM:SS" timer in the HUD, with hundredths-of-a-second precision. I could avoid such frequent allocations by only having integer seconds resolution, so I'd only have to generate a new string in 1/60th of the frames instead of all of them. The other allocation is in my AI logic. Here, the AIShipController.Waypoint function is being invoked 8 times this frame (I guess a lot of ships wanted to know where to go), and it does some direct allocation. If I look at that function, it looks like this: code:Finding slow code uses a similar process, except you sort based on time instead of allocations. I didn't show you that for my code because I've already put a lot of work into optimizing my CPU time, so it's mostly not very easy to say "this bit is slow because it does X". But in general, your best method for making your code faster is to have it do less work. Oftentimes things are slow because you're recalculating a value every time you need it, or because something is updating every frame when it only needs to update every few frames. For example, I nearly doubled my projectile performance by having all of my projectiles only test for collision every other frame, but with bigger hitboxes. The gameplay difference is imperceptible, but it saved me maybe 10% of my runtime when there's a lot of stuff flying around. I hope this is a helpful starter. If you have specific questions, feel free to ask and I'll do my best to answer them.
|
|
#
?
May 2, 2021 04:19
|
|
|
TooMuchAbstraction posted:Rule one of performance is "don't worry about it until it becomes a problem". What causes performance issues is often hard to predict, and best solved with a profiler. And unless you're targeting a platform with limited capabilities, your performance issues are far more likely to be caused by poor algorithms than by inefficient graphics. Yes but I feel if I go that far, it'll be a nightmare to undo the damage I did.  Aiming for basic pc and that's about it. No delusions of grandeur. Just doing something for myself! I don't think having a sprite sheet full of 4K frames is exactly a good idea though. I've searched for a good rule of thumb on that for hours/days and there isn't much out there.
|
|
#
?
May 2, 2021 04:44
|
|
|
The Titanic posted:Yes but I feel if I go that far, it'll be a nightmare to undo the damage I did. If you start making stuff and later decide that you've made them too big it's a pretty easy solution: reduce the size of your sprites. If you decide that you've made them too small it's much harder to correct.
|
|
#
?
May 2, 2021 04:48
|
|
|
The Titanic posted:Yes but I feel if I go that far, it'll be a nightmare to undo the damage I did. That in mind, again, don't worry about performance until it becomes a problem. Then figure out which nasty pile of crappy code is the one actually giving you issues, and figure out how to fix that part and only that part, instead of trying to optimize everything the first time you write it. quote:Aiming for basic pc and that's about it. No delusions of grandeur. Just doing something for myself! Find something that looks good to you and go with that. Don't overthink it. 99% of indie gamedev projects die on the vine anyway, so anything you can do to keep yourself churning away at making the game, however flawed it may be, is better than spending more time worrying about whether or not you're doing it correctly.
|
|
#
?
May 2, 2021 04:49
|
|
|
the difference in reliability in code ime is entirely explained by testing practice. games peeps test almost entirely manually so it sucks, enterprise peeps test almost entirely semi-manually (writing unit tests manually) so it sucks marginally less. chip designers prove poo poo and fuzz poo poo and do fully automated testing (where the rig writes the tests) and random testing. but that requires qa peeps who actually know how to actually code, which is more difficult to whack in into an org than you think and infeasible in indieland
|
|
#
?
May 2, 2021 04:55
|
|
|
TooMuchAbstraction posted:Rule one of performance is "don't worry about it until it becomes a problem". Thanks for the excellent write-up, that's exactly what I was looking for! Question though: what constitutes a "problem" in your opinion? Noticeable slowdown? Under 60fps? Under 30? Something else?
|
|
#
?
May 2, 2021 04:59
|
|
|
bob dobbs is dead posted:the difference in reliability in code ime is entirely explained by testing practice. Yeah, it's for sure possible to have a clean, tidy codebase even if you have large groups of contributors. And definitely, good test coverage is essential to being able to work at any kind of useful pace in an industry setting. Being able to say "I'm just going to make the apparently-correct change and trust that the tests will tell me if I've violated some assumption elsewhere" is really useful for peace of mind. But what I was trying to get at more was that it's simply not possible for you to remember how your entire project works all the time, even if you're the only person who wrote it. You're going to have to open up some file that you haven't touched in awhile and re-learn how it works, whether it's because you need to fix a bug / performance issue, or because you need to add functionality to it. That is what I meant by "legacy code": it's code that nobody understands any more. In other words: get comfortable with not knowing how stuff works. That's the default state of the programmer. CodfishCartographer posted:Thanks for the excellent write-up, that's exactly what I was looking for! I'm glad it was helpful! Where you draw the line is up to you. Vlambeer made plenty of very successful games that run at 30FPS, for example, while some devs swear that they must absolutely keep above 120FPS. My goal generally is to keep stable 60FPS and to minimize "hitches", where there'll be a single frame that takes noticeable longer than the ones around it. That latter is why I keep tabs on my memory allocations; when the Unity garbage collector runs, nothing else can run, so if there's a lot of memory flying around, it's easy to end up freezing things so that unused objects get de-allocated. But I don't know what a reasonable amount of memory is to allocate per-frame, especially now that Unity has an incremental GC. TooMuchAbstraction fucked around with this message at 05:07 on May 2, 2021 |
|
#
?
May 2, 2021 05:04
|
|
|
Second question, you mentioned not running the profiler all the time - when do you run it, when you notice problems and are trying to repro them / pin them down?
|
|
#
?
May 2, 2021 05:22
|
|
|
I'm working on my first game, and I'm trying to improve the math for it. Right now I just have almost everything hard coded based on some napkin math I did, but I would like to change everything over to formula's. Does anyone have any good recommendations for a good place to read up on the math aspect behind games? Primarily the math behind calculating damage based on stats, and having it scale with levels and gear.
|
|
#
?
May 2, 2021 05:22
|
|
|
Bahanahab posted:I'm working on my first game, and I'm trying to improve the math for it. Right now I just have almost everything hard coded based on some napkin math I did, but I would like to change everything over to formula's. Does anyone have any good recommendations for a good place to read up on the math aspect behind games? Primarily the math behind calculating damage based on stats, and having it scale with levels and gear. But what you're looking for is calculating damage based on player and equipment level, so basically you'd need to code in the formula you want to use and fill in the variables with whatever stats you're using. Which means some basic algebra, with maybe some probability/statistics for implementing dice rolls?
|
|
#
?
May 2, 2021 05:44
|
|
|
Oh my project works normally in Unity 2020 now. And of course now I can't remember why I was interested in 2020 over 2019.. uh..oh well. Boy is Package Manager a lot nicer than updating stuff through the damned Asset Store window.
|
|
#
?
May 2, 2021 07:13
|
|
|
CodfishCartographer posted:Second question, you mentioned not running the profiler all the time - when do you run it, when you notice problems and are trying to repro them / pin them down? also if your game randomly goes to poo poo now and then, try installing throttlestop and checking if it's a hardware issue. I wasted weeks in the profiler trying to find a source for my lag spikes, only to find out it was my laptop CPU activating turbo mode, then hitting the temperature limit and slowing way down for a few seconds.
|
|
#
?
May 2, 2021 08:12
|
|
|
bob dobbs is dead posted:the difference in reliability in code ime is entirely explained by testing practice. This is the world I'm used to (enterprise level with a full staff qa department and automated testing suites). So me "just doing something until it breaks" is not easy because that's not how I think. I'll never do this with my project, but I got to have a well planned execution to start with.
|
|
#
?
May 2, 2021 14:08
|
|
|
Tip posted:If you start making stuff and later decide that you've made them too big it's a pretty easy solution: reduce the size of your sprites. I agree and this is acceptable; unless I plan pixel art from the start. That doesn't scale down correctly on a per pixel level.
|
|
#
?
May 2, 2021 14:10
|
|
|
CodfishCartographer posted:Second question, you mentioned not running the profiler all the time - when do you run it, when you notice problems and are trying to repro them / pin them down? Yep. Or if I get a report of bad performance from a playtester. EDIT: something I forgot to mention: the Unity editor slows down significantly for me once I've used the profiler. So when I'm done profiling, I close the profiler window and then restart the editor. TooMuchAbstraction fucked around with this message at 18:16 on May 2, 2021 |
|
#
?
May 2, 2021 14:48
|
|
|
The Titanic posted:I've downloaded and installed it. I'm probably going to have to play with it at this point. Echoing first the don't worry about problems until they're actually problems thing in gamedev. I use Godot a bunch for 2D stuff. It's got a lot of pixel-perfect convenience functions (especially in the new version) which are great if you're some kind of weird purist who insists that everything aligns to the exact pixel (even if the maths would imply a fractional result): https://twitter.com/StrangeHill2DO/status/1185024739263205376 (I really should save my videos elsewhere because the Internet loves to recompress and ruin things but even that oldschool tilting shader only cuts images up along the whole-pixel bounds). And I've got a separate hobby project for which I appear to have saved no screenshots but it's got an incredibly simplistic art style and just for laughs I drew everything at 8K resolution and just have it scaled down as-is appropriate in-engine. Doesn't even register on the profiler, though granted I also don't have any traditional (frame-by-frame) animation in that project. But yeah, 2D in Godot is a first-class citizen. And a joy to work in overall. As a previous poster said, the node system and observer pattern align with my sensibilities better than any other engine I've used, even the ones I've written myself.
|
|
#
?
May 3, 2021 15:29
|
|
|
I'm working with Unreal, and some tutorials and vendor websites have basically said "take this animation, and slap it on your character." I thought animations could only be applied to models with their rig. Does everyone working on Unreal projects just use the default mannequin? Do Unity people do that too? Is it a good idea? When would you make an exception?
|
|
#
?
May 3, 2021 20:38
|
|
|
Cheston posted:Does everyone working on Unreal projects just use the default mannequin? Do Unity people do that too? Having seen a lot of the crap on Steam, yes, users of both engines absolutely do that
|
|
#
?
May 3, 2021 23:04
|
|
|
Cheston posted:I'm working with Unreal, and some tutorials and vendor websites have basically said "take this animation, and slap it on your character." I thought animations could only be applied to models with their rig. Does everyone working on Unreal projects just use the default mannequin? Do Unity people do that too? Is it a good idea? When would you make an exception? So this is the double edged sword I slowly impaled myself with. I started off looking for something to get me rolling, and that basically led to ALS, for the awesome movement system and I could skip a lot of the basics. But I had to use their general skeleton setup. So first I exported it into Blender, and made all my necessary bone additions without affecting the original skeleton so it kept working as advertised. I was able to finally get something where I could retarget to my skeleton that worked... I don't think there are any tutorials on this that is 100% accurate. Veering away from the stock skeleton seems like a mostly bad idea, as well. Retargetting can be good but it's a mess. All of the Blender import stuff failed to work for me as well as soon as my models and skeletons were of a slightly complex nature, so I had to use the export to FBX and re-import into Unreal. At the point of animation, actually learning the intricacies of ALS was hard. It is also broken out of the box, but you won't learn that until later and then you have to fix a variety of nonsensical graphs. But you'll feel somewhat accomplished My thought is that the default skeleton is useful, and it comes with a lot of stuff that seems like it would save you tremendous time, but it's a trap. You're probably almost better off just rolling your own skeleton and movement system and knowing how to add stuff to it than getting something that seems easier but is overly complex and actually broken. If you don't go for ALS you get to make a movement system, and that's a trap too because everything in unreal has this sort of easy nature to it that makes you want to go to that next level without realizing it's a complex network of confusion.
|
|
#
?
May 3, 2021 23:26
|
|
|
kirbysuperstar posted:Having seen a lot of the crap on Steam, yes, users of both engines absolutely do that There are people out there who also never replace the default mannequin, and make kickstarters with it. :3 Also sometimes actually changing from the default texture is just too much sometimes too. But if people buy it and they're happy... more power to them!
|
|
#
?
May 3, 2021 23:28
|
|
|
Hammer Bro. posted:Echoing first the don't worry about problems until they're actually problems thing in gamedev. I have not played with it yet. I'm back to worrying if learning a scripting language is less smart than just going with unity and using a known language.  I'm also debating sacrificing doing all the little fiddly pixel animation stuff with just larger animations that I don't have to really worry about pixels looking pretty quite as much and just draw stuff. My latest thinking is 256x256 and scaling it down to whatever I want and doing sort of blah-pixel art that's not really pixel level stuff with that amount of meticulous thinking but it's low resolution. Needless to say I could care less about pixel perfect positioning I think. But genuinely I don't know. The move away from 3D has me scared of failure!
|
|
#
?
May 3, 2021 23:33
|
|
|
Cheston posted:I'm working with Unreal, and some tutorials and vendor websites have basically said "take this animation, and slap it on your character." I thought animations could only be applied to models with their rig. Does everyone working on Unreal projects just use the default mannequin? Do Unity people do that too? Is it a good idea? When would you make an exception? There's a sorta industry standard for biped humanoids to have certain bones, pelvis, 2 spines, head, arm, elbow, feet, and if your animations are designed for that they can be slapped on other characters pretty easily. I'm no expert in rigging, its probably my weakest knowledge area for game dev, but this has worked for me so far. For non-humanoid types though, things get a lot less standard and it becomes more "this animation is designed for this model" and another model working with the same animation is either getting lucky or having them both be specifically designed for the same animation. And yeah using a free character model that comes with the engine that everybody has works pretty well as a standard default, and then you can build another model to use the same rig and you're off to the races. But again, that kinda only works for biped humanoids. (the default mannequin shape)
|
|
#
?
May 3, 2021 23:34
|
|
|
Zaphod42 posted:There's a sorta industry standard for biped humanoids to have certain bones, pelvis, 2 spines, head, arm, elbow, feet, and if your animations are designed for that they can be slapped on other characters pretty easily. I'm no expert in rigging, its probably my weakest knowledge area for game dev, but this has worked for me so far. The unreal character, at least the one I worked with, had a lot more than that. It made weighting a pain in the butt also, and getting the IK rig to work was another shore of evil. I should just return to modding Doom
|
|
#
?
May 4, 2021 00:33
|
|
|
The Titanic posted:I have not played with it yet. I'm back to worrying if learning a scripting language is less smart than just going with unity and using a known language. Yeah, unfortunately I can't comment on the performance other than tilemaps making my 2 year old thinkpad (with Intel graphics) turn into a helicopter. I haven't figured out why so that's pretty fun I'm targetting toasters via html5+websockets for my game and I guess the trick there is to use GLES2 rendering until Godot 4.0 saves the day with the new renderer fanciness. Until then... I'm waiting  For what it's worth, you can use C# with Godot. It's officially supported per a development donation from Microsoft.
|
|
#
?
May 4, 2021 00:41
|
|
|
|
| # ? Jun 3, 2024 13:39 |
|
|
The Titanic posted:The unreal character, at least the one I worked with, had a lot more than that. There's a reason "boomer shooters" are popular in indies right now!
|
|
#
?
May 4, 2021 00:45
|
|