|
Raenir Salazar posted:drat Unreal really looking attractive to me right now. Come on over. I can't emphasize enough how nice it is to work every day without worrying about seeing a dumbshit headline about the CEO's latest BIZNESS move.
|
#
¿
Sep 12, 2023 21:51
|
|
|
|
| # ¿ May 11, 2024 16:30 |
|
|
xzzy posted:Yeah, 'ol Sweeny has never gone to war against companies running online marketplaces and gotten his most profitable title (temporarily) pulled. They have a long, proven track record of doing the right thing when it comes to UE. They start fuckin' that up, we're having a different conversation. But until then, saying "both sides heh  " is a real laugh and a half.
|
|
#
¿
Sep 12, 2023 22:54
|
|
|
emanresu tnuocca posted:unreal's blueprints are different from game maker and unity's visual scripting thingies, they are not an semi functional alternative to code they are meant to extend code and give designers more immediate access to game and software logic, I like them a lot and when I split tasks with a cpp developer it often seems like the right solution often presents itself faster via blueprints, and although often stuff gets difficult to maintain it often brings certain features to a point where they're 'good enough' and you won't need to look at them for a while. Lyra is an incredibly useful resource to help point devs to various engine features, but the result is a game where powerful engine paradigms are relegated to exactly one tiny in-game result lol. As a result it's super overengineered for what it actually is. It still beats the alternative. Anyone remember Gigaya? The project Unity started to demonstrate Unity's strengths and feature-complete systems for shipping games? The project they cancelled because, as it turns out, Unity isn't a game engine but rather 49 half-baked alpha features in a trenchcoat? Unity sucks a lot. I started with it before switching to Unreal many years ago and I have no idea why anyone defends it other than a long-false myth that it's 'easier' than Unreal.
|
|
#
¿
Sep 14, 2023 16:34
|
|
|
TooMuchAbstraction posted:Like, you can argue about the reality vs. the perception, or the relative qualities of the two products, but I think that's an accurate description of how the two engines were perceived. Can't argue with that. TooMuchAbstraction posted:Perception matters, and Unreal's perception, for a long time, has been "this engine can do anything, but it also has a cliff-like learning curve and the knowledge base is mostly locked up inside the brains of AAA developers who aren't allowed to talk about their work" That's fair, too. But I've worked in UE both at the indie and AAA levels, and to be honest there aren't that many super-secret resources available only to higher level professionals. By and large the knowledge base/documentation is the same for both groups: looking at the source code for whatever thing you're trying to figure out.
|
|
#
¿
Sep 14, 2023 16:51
|
|
|
Embrace the Select Node in blueprints and you'll never go back to whining about visual scripting being too messy. Also do normal programming things like not having a metric poo poo ton of logic in one event or method. You know, super basic principles. All scripting is messy if you suck at it.
|
|
#
¿
Sep 16, 2023 18:29
|
|
|
None of that is how writing for games works. If this person is willing to pay you what you’re worth then go nuts. But be advised you’re almost certainly not going to learn anything about working on games on a project like that. Like LOL at calling for a “final story” while still in pre-production
|
|
#
¿
Sep 16, 2023 23:19
|
|
|
Godspeed, friend.
|
|
#
¿
Sep 16, 2023 23:56
|
|
|
I wanted to chime in with some help but I'm having trouble parsing what you're actually trying to do.
|
|
#
¿
Oct 1, 2023 15:17
|
|
|
Just use a blueprint interface, homie.
|
|
#
¿
Oct 5, 2023 00:19
|
|
|
You’re trying to set a reference to something that only exists at runtime, that’s why you’re only seeing None. What are you actually trying to do? BPIs make communication between classes very simple, but I need to know what you’re trying to do to be able to explain it helpfully.
|
|
#
¿
Oct 5, 2023 02:40
|
|
|
That’s a weird quirk of interfaces, yeah. When you create a BPI function that doesn’t return anything, it will implement as an event. If you create a BPI function that does return something, it will implement as a function (because events can’t return data).
|
|
#
¿
Oct 6, 2023 12:34
|
|
|
I'm still confused about the whole 'setting the interface as a variable' thing, which is something I've never done or even heard of in several years of using UE professionally. BPIs are very simple to use. You create the BPI, then inside it you add the function you want, then implement both the interface and the function you made on the actor you want to do stuff with or to, then you call that function from another class which will make all this to happen (like a trigger volume or whatever). You don't need to (and should not) cast anything. All you need is a generic reference to the class that has the interface and functionality on it (or one of its parents) and call the BPI function from that reference. The nice (and for beginners, kind of confusing) thing is that if you call a BPI function on a class that doesn't implement it, it will fail silently, which is almost always what you want. If necessary you can check for failure by using the node "Does implement interface" before actually making the BPI call, so you know for certain why something isn't working. If all this is still confusing let me know and I'd be happy to take some screenshots or a quick video or something. BPIs are awesome, straightforward, and how I handle the vast, vast majority of class communication (outside of one-to-many situations where event dispatchers work best). Chillmatic fucked around with this message at 16:01 on Oct 6, 2023 |
|
#
¿
Oct 6, 2023 15:47
|
|
|
ZombieApostate posted:Quick and dirty example. 2 Actors, Door and Trigger. Add a Trigger variable to Door of the TriggerBP type and make it instance editable. Set the trigger on each instance in the map editor and done. Unless I forgot to mention something. Oof, yeah this is...not the way to do this sort of thing. Not trying to be a jerk but event-driven logic is massively overcomplicated for a simple one-to-one communication use case. You also want to avoid hardcoding references in the instance like that (your red circle), because now all other logic depends on that assumption and changing things becomes a pain in the rear end. Chillmatic fucked around with this message at 15:58 on Oct 6, 2023 |
|
#
¿
Oct 6, 2023 15:55
|
|
The bit circled in red is where you set the trigger.
|
You're hardcoding not only a specific instance of a specific door, but also assuming the class "BP_Door" will always be the class that this is called on. This can be done with just a few nodes, no assumptions, and no instance-specific references or hardcoding of any kind. I think I'll make a short video showing optimal class-to-class communication because the solutions I often see employed are either over-engineered or else brittle and full of assumptions. Chillmatic fucked around with this message at 18:27 on Oct 6, 2023 |
|
#
¿
Oct 6, 2023 18:23
|
|
|
emanresu tnuocca posted:an instance editable variable is not hard coded. Instance references must be set by hand, can't be changed at runtime, and have to be specifically set with something or else return null errors. We may have different definitions of what hardcoded means, but this is what I'm referring to. Sometimes you can't avoid it, but I'm not seeing where it makes sense to do this for simple class communications.
|
|
#
¿
Oct 6, 2023 18:55
|
|
|
emanresu tnuocca posted:if you have a simple game that has various buttons/triggers that open specific instances of doors in your level this is just about the easiest way to link the right buttons to the right doors on the level of the level editor, which may be desired. You're right about that. I think I'm just used to approaching more systemically because bigger games essentially force you to, and working with a large team you have to design things so stuff doesn't break when someone changes something.
|
|
#
¿
Oct 6, 2023 19:20
|
|
|
There are definitely multiple ways to do things in gamedev, and I know better than to make it sound like there's a One True Way. Sorry about that, y'all. I think I get frustrated because when I was starting out the tutorial scene was full of terrible practices and people just 'doing stuff' without explaining why, and for all I know it's still like that. Most likely I'd have benefited from more structured advice like "use X when you're trying to do Y", which is really what I've been doing sub-optimally, here. ZombieApostate posted:I would actually like to see this, it's always nice to see how other people do things. Sure, I can put something together. Does anyone else have questions or want to see something covering how to communicate between classes, when to use what, etc?
|
|
#
¿
Oct 6, 2023 23:12
|
|
|
Of course, but it's also important to cover fundamentals before delving into things you may or may not end up needing. That's why I've been talking about setting up even simple systems as generically as possible, so they're easier to grow and modify smoothly alongside the game you're working on. When I was starting out, few things frustrated me as much as having to revisit some old system I'd made previously, and hitting a brick wall full of assumptions and magic numbers and hard casts and giant methods/classes and pretty much all the big bad smells.
|
|
#
¿
Oct 6, 2023 23:59
|
|
|
more falafel please posted:Yeah, but just as annoying is the super overengineered perfectly abstract system where you have to hook up 17 objects, write some custom callbacks (but first define a new CallbackReceiver subclass), add two new global enums, and adjust the behavior of a state machine just to call a function. who on earth suggested doing something like this? blastron posted:just do the hackiest thing that lets you do that, with the understanding that at some point soon you'll probably need to tear it up and build something more comprehensive. I don’t disagree at all with getting gameplay in, first, and then optimizing/patterning shortly after. Chillmatic fucked around with this message at 04:07 on Oct 7, 2023 |
|
#
¿
Oct 7, 2023 04:03
|
|
|
Class-specific custom events are not related to what you're trying to do, and event dispatchers are a a very different concept, but godspeed.
|
|
#
¿
Oct 7, 2023 16:06
|
|
|
Rocko Bonaparte posted:2. Does UE5 have some logic already to handle stacking of menus? I had to create a stack of controller contexts to do this in Unity. Say, normally the stack is just one element and it's the main game that's going on. Then the player triggers a menu, which transfers control inputs to that UI. They then do something that prompts a dialog, which transfers control to that UI. They make their choice, which "pops" that UI's control back to the menu. They close the menu, which pops it back to the main game. It's hard to understand what you're actually asking. Stacking of menus in UI--as in, displaying multiple UI elements at a time and deciding which one gets input priority--is done by adjusting the z-order in the widget class itself. If you're asking how the engine handles consuming input for UI vs. game purposes, there are built-in functions that you can call on the widget class itself that handle this.
|
|
#
¿
Oct 16, 2023 16:21
|
|
|
Rocko Bonaparte posted:It's more like making sure any previous game or UI stuff gets no inputs at all until the current active one is satisfied and closed. Consider something like a game going on where the direction buttons would move the character, then the main menu on top of that, then the save menu on top of that, and then a dialog prompt about deleting a save. You don't want any buttons going to the character, nor do you want anything to even go to the save menu. It's all on the confirmation dialog. Yes, I explained all of this in my response to you.
|
|
#
¿
Oct 17, 2023 03:26
|
|
|
Pyrolocutus posted:I'm aware this is more of a thread devoted to working on games proper, but I asked in the SH/SC general megathread about recommended hardware to do UE5 game dev and was pointed here. Following what everyone else has said--just "running the editor" is possible on pretty much any machine with a GPU less than five-six years old. As for how much more than that you need, a lot depends on the kind of game you're looking to make. If you want higher fidelity graphics/animations etc. you'll need a somewhat powerful system due to being unoptimized for however long in development.
|
|
#
¿
Jan 23, 2024 16:00
|
|
|
Rocko Bonaparte posted:Unreal Blueprint code gets into some serious spaghetti really quickly. I think my main issue is with reusing return values. Say, I have an object to which I'll be doing a bunch of stuff in a row. A sequence will give a top-to-bottom ordering but won't stop me from having to connect that object in a fan to all of the different commands. Is there a better way to do this? Just save it to a temporary variable and drop that next to every command? You fix this by doing the exact same things you would do in a text-based language. Also, if you’re working within a function that has inputs/arguments, Unreal automatically turns them into local variables scoped to the function, so you don’t even need to run a wire from the input to wherever it needs to go.
|
|
#
¿
Feb 25, 2024 21:23
|
|
|
quote:I'm guessing I should create a bunch of these if I want easy, but separated access to different animations. I almost never have any idea what you're talking about. But I'm pretty sure you've been told multiple times that animation montages are what you are looking for, and for some reason you keep ignoring the advice or missing the point.
|
|
#
¿
Apr 2, 2024 22:29
|
|
|
jizzy sillage posted:An Animation Montage is a combination of one or more Anim Sequences. You can chain three AnimSequences together in a single AnimMontage if they're meant to be played back to back. I think descriptions like this can get confusing/contradictory. Animation Composites are the class/object that are actually intended to combine animations in UE. Montages can also do this but over the years their purpose has morphed into being "fire and forget" one-off animations that can be called from any object in code or script. They've become popular for things like attacks, transitions between movement states, and traversal actions such as mantling/climbing. Montages can be played on specific, custom-defined skeletal layers like "upper body", useful for things like reloading animations which should not affect or influence the lower body bones (just as one example). Rocko Bonaparte posted:There's some semantics/taxonomy crap going on here that I'm slowly understanding (I hope!). No doubt. Epic does a terrible job at teaching and describing things. For example blueprint interfaces are something they teach as a "one to many" communication class, like for calling the same functionality but overridden/differently implemented on a per class basis...but neglects to ever mention how ideal they are for simple class communication and passing data around, especially in contrast to casting, hard level references, and other expensive crap. Ultimately I don't think that Unreal's built in animation stuff is ready for shipping or general use. For what you're describing with spears etc. it would be exponentially less time-consuming to author the anims in blender/maya or whatever, and then invoke them in the engine. Attach the spear to the socket/bone of your choice, look into weapon-hand IK setups, and be off to the races.
|
|
#
¿
Apr 3, 2024 13:06
|
|
|
Can you post a screenshot? I’m not sure what you mean about an event as a variable.
|
|
#
¿
Apr 9, 2024 00:34
|
|
|
I'm still not sure what the problem is or what you're asking for. There is the "create event" node which can be used to bind/unbind/assign event dispatchers, as such: 
|
|
#
¿
Apr 9, 2024 13:58
|
|
|
Raenir Salazar posted:I feel like I was pretty clear with my screenshot Good luck with whatever you’re trying to do. Raenir Salazar posted:e: What the gently caress Unreal, apparently you can't have events inside functions they have to be all in the main event graph You can call events from within functions. If you are asking why you can’t create events inside functions, that’s because functions do not allow latent actions like delay, timelines, etc. You can create multiple event graphs if you would like to keep different categories of events on their own graph.
|
|
#
¿
Apr 9, 2024 17:09
|
|
why.
|
You are fighting the engine's architecture, on multiple fronts, for no discernible reason. You do not understand fundamentals like the game thread itself, the difference between synch/async actions, and the differences between very basic stuff like events vs. functions. You'll get less angry and frustrated if you watch some tutorials and/or read the documentation. Raenir Salazar posted:I still don't know for sure if "Create Event" is "good" but I guess I'll never know for sure and some poor Unreal Engine developer is slowly aging like I stepped on a crack on the sidewalk. You asked for an obscure solution to a problem that isn't common knowledge, and I provided it to you. Rethink being a dingus when you're asking for help.
|
|
#
¿
Apr 11, 2024 01:41
|
|
|
Red Mike posted:blueprint code becoming a spaghetti mess I have a weirdly personal vendetta against this line of thinking, mostly because in all honesty I love Blueprint. The last big studio I was at switched to UE for their current project, and I was the "Blueprint Person" that engineering would ask questions to when they didn't want to dig around in source. It's one of my favorite scripting languages, and it drives me crazy when people think it has to look like poo poo or be impossible to reason about. In eight years I don't think it's ever failed, when someone's blueprints look like this, they inevitably complain that cpp would make this all so much "Cleaner" and "More elegant", and when I look at their typed code it's the exact same kind of nonsense but this time in text form and even more impossible to understand.  Basically I think Blueprint bothers people because it doesn't give bad programming practices any place to hide; it makes spaghetti actually look like spaghetti. It is perfectly possible to make an entire game using it, and the only valid criticism I've seen about the format is that version control and merging is indeed a nightmare. That's a good enough reason on its own to minimize their use if that's an issue on larger teams. But messy blueprints are an unforced error on the part of the user, not an inevitable end result.
|
|
#
¿
Apr 12, 2024 23:16
|
|
|
xzzy posted:My only complaint with node based editors is I've been using a keyboard as my primary interface for decades, and moving to something mouse based feels really slow. I totally get that, yeah. The UE team could do a lot more to improve on this but stupidly it doesn't seem to be a priority. aardvaard posted:Specifically, I don't think wires crossing wires is blueprint code smell, as long as you can still trace the connections. Adding nodes to your wires helps a lot with this. Definitely. There are also a lot of other tips and tricks like: rather than dragging lines from function inputs/arguments all the way over to whatever they connect to, using the built in local variables that UE creates automatically for you, that way you can connect them right next to where they go. You can also press Q to automatically straighten a line of nodes, as well as alt-shift-S to align vertically. quote:One important thing to learn is that a beautiful blueprint isn't necessarily more maintainable than an ugly one. Getting caught up in keeping everything aligned, making all the wires straight, is a fun bit of yak shaving but not necessarily productive. The important thing is that, like code, it's readable. A beautiful blueprint that takes me twenty minutes to decipher is not better than a straightforward ugly one. Completely agree, except to say that all of this applies to typed code as well. Like man I have known some engineers who will kill themselves to create beautifully indented code with comment sections that border on ASCII art, and inevitably their poo poo is still really difficult to reason about. When I say "messy", I mean less about aesthetics and more about programming smells in general. Chillmatic fucked around with this message at 23:52 on Apr 12, 2024 |
|
#
¿
Apr 12, 2024 23:46
|
|
|
Stop being an insufferable rear end in a top hat, and instead show appreciation for those willing to spend the time to answer your requests for help.
|
|
#
¿
Apr 13, 2024 23:00
|
|
|
|
| # ¿ May 11, 2024 16:30 |
|
|
This touches on why a lot of younger/less experienced devs either hate or are super reluctant to use C++. It requires you to understand and think about the hardware you’re working with. Like pointers are the easiest thing in the world to understand, if you know what memory is and how it works; otherwise it’s just this crazy abstract concept.
|
|
#
¿
Apr 28, 2024 13:50
|
|