|
Holy gently caress I'm old I have no goddamn idea what any of this means.
|
#
?
Jan 14, 2024 13:51
|
|
|
|
| # ? May 18, 2024 21:03 |
|
|
KillHour posted:Holy gently caress I'm old I have no goddamn idea what any of this means. ok boomer
|
|
#
?
Jan 14, 2024 14:48
|
|
|
Is there some way in Unreal Engine to serialize animation, and possibly also control state? I'm wondering how close I can get to saving the state of the player mid-step and continuing to run in a direction if that control was pressed right before the save and was still pressed when it was loaded. That's a difference between being able to save whatever/whenever/however and having to use save points to kind of just stabilize everything. I can't really say I had something similar in Unity because I was mostly just testing with a rectangle as the player, but the default 3rd-person pawn in Unreal brings this unresolved issues up to the front faster.
|
|
#
?
Jan 16, 2024 16:12
|
|
|
That's bad juju; animations should always be stateless. I suppose you could save out the inputs and apply them until the player overrides them after load, but that would be weird too - imagine you're walking toward the edge of a cliff when the autosave kicks in, you fall off, and then the checkpoint reloads you onto the top of the cliff with a forward input applied.
|
|
#
?
Jan 16, 2024 21:46
|
|
|
The scenario I care the most about is the UX from going from one level to another. It's a transition to another, connected place and I didn't want to endlessly stream it all or something. Like going from some section of an overworld to a dungeon or from one floor of a dungeon to another. If they, say, run west through the exit, when they arrive in the other place, I'd rather not have a split second for the player pawn to animate and play it shifting its weight forward before moving again. Saving and loading is involved there because of the level transition, although it wouldn't normally be a save game itself. There are a few ways to skin that. I could just get rid of that pause in the animation itself. I wondered what other stuff I could try. Getting screwed by autosave has all kinds of fun ways to manifest. I could just as well say that the player was saving as they were dodging an attack, but when they reload, they now start stationary and get killed by it each time.
|
|
#
?
Jan 16, 2024 23:17
|
|
|
You're overthinking this. If you look at what published games do for this kind of thing, you'll consistently see one of these solutions: 1. character always spawns in the new zone standing idle (often, but not always, because they went through a door or other trigger) 2. character automatically runs into the new zone, regardless of how they left the prior zone. That is, the game takes over control of the character for a second or so to show them running in from off the edge of the screen. 3. new zones are seamlessly streamed as needed You're (quite reasonably) not willing to do #3, so do one of the first two instead.
|
|
#
?
Jan 17, 2024 00:19
|
|
|
Good news, it looks like a bunch of the rendering errors in godot's 2d pixel engine are getting fixed in the next release. All the sprite bleed and jitter i have seems to be resolved
|
|
#
?
Jan 17, 2024 04:11
|
|
|
Rocko Bonaparte posted:Getting screwed by autosave has all kinds of fun ways to manifest. I could just as well say that the player was saving as they were dodging an attack, but when they reload, they now start stationary and get killed by it each time. What's the intended goal of your autosaving system such that you're at risk of softlocking the player if the save catches them mid-input? That implies a very granular system that saves and restores practically all state, which has a whole host of both design and technical issues. Is there a reason you want to do it that way, rather than something that's less precise but more deliberate?
|
|
#
?
Jan 17, 2024 06:11
|
|
|
I don't know if I'd even call it autosaving even if a system that works over some arbitrary time interval like that has the same problems with saving state. I was just having some pretty good luck serializing state until I got to this particular situation. I've looked up some stuff since and saw something from somebody that did have a compelling case for (well, according to them) that ended up having to modifying the Unreal Engine source to do it. That's about at that level where I'd definitely stop. I was generally just hoping I'd be able to replicate that state and I was having decent luck with it in Unity before moving over to Unreal. Then again, I hadn't gotten to animation state and stuff like that there either.
|
|
#
?
Jan 17, 2024 08:42
|
|
|
If I wanted to be able to perfectly restore game state, I'd make a game where I manually control all relevant memory, and just serialize the memory block in its entirety, like emulator save states. Yes, this does mean doing pretty much everything by hand, instead of using an engine.
|
|
#
?
Jan 18, 2024 01:57
|
|
|
Tunicate posted:Good news, it looks like a bunch of the rendering errors in godot's 2d pixel engine are getting fixed in the next release. All the sprite bleed and jitter i have seems to be resolved Link to source? I can’t find anything about that online yet.
|
|
#
?
Jan 18, 2024 06:36
|
|
|
TooMuchAbstraction posted:If I wanted to be able to perfectly restore game state, I'd make a game where I manually control all relevant memory, and just serialize the memory block in its entirety, like emulator save states. Yes, this does mean doing pretty much everything by hand, instead of using an engine. Don’t forget all registers too!
|
|
#
?
Jan 18, 2024 06:53
|
|
|
Gary the Llama posted:Link to source? I can’t find anything about that online yet. talked with one of the devs and listened in on the latest pixel perfect rendering discussion. My two test builds which have big jitter/bleed issues (one of which from 2022) both now work in his latest version. PR is going up for that soon, and it looks like there's going to be a lot more work on other pixel rendering stuff in general
|
|
#
?
Jan 18, 2024 07:34
|
|
|
TooMuchAbstraction posted:If I wanted to be able to perfectly restore game state, I'd make a game where I manually control all relevant memory, and just serialize the memory block in its entirety, like emulator save states. Yes, this does mean doing pretty much everything by hand, instead of using an engine. Lots of fighting games use a lockstep networking model with prediction and rollback: you send your input state to the other player every frame, assume that the other player's input for frame X is the same as it was for frame X-1, and when that input actually comes in, if I differs, roll back your game state to what it was before X and resimulate X, X+1, X+2, etc until you catch back up. This requires two things: a gameplay tick that can be run several times in a single frame's time slice, and a deterministic gameplay state that's small enough to store several copies of, so that two different machines running the game tick with the same inputs and same state produce the same output state.
|
|
#
?
Jan 18, 2024 16:44
|
|
|
Is the norm for cataloging saves in Unreal to save the catalog in a hard-coded slot? That is the closest I saw to a pattern for platform-independent save management. I was figuring there would be a c++ function to get all used slots or whatever, but I just can't dig one up. Apparently, standard library stuff is frowned upon there, so that's all I sorted out as a solution.
|
|
#
?
Jan 19, 2024 17:36
|
|
|
Out of curiosity: anyone here using DragonRuby for anything (e.g., development on a project, tinkering with ideas, tire-kicking DragonRuby itself, etc., etc.)?
|
|
#
?
Jan 20, 2024 09:57
|
|
|
Self-responding:Rocko Bonaparte posted:Is the norm for cataloging saves in Unreal to save the catalog in a hard-coded slot? That is the closest I saw to a pattern for platform-independent save management. I was figuring there would be a c++ function to get all used slots or whatever, but I just can't dig one up. Apparently, standard library stuff is frowned upon there, so that's all I sorted out as a solution. Apparently in newer releases of the engine, they finally added some function to actually get a list of all the saves, so having to save out a catalog of saves isn't necessary. Somebody elsewhere had brought up doing that was annoying if you were sharing saves with another developer. I agree with that, and makes me wonder how it was done in UE4 where I don't think those functions were available.
|
|
#
?
Jan 20, 2024 10:52
|
|
|
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. If there's a better thread I'd be happy to pop over there, but I'm interested in hardware recs for UE5 dev. I don't need top of the line but "good for the job" would be nice.
|
|
#
?
Jan 22, 2024 23:53
|
|
|
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. Are we talking just working in the editor? Compiling the whole engine from scratch? What's your shader count look like?
|
|
#
?
Jan 23, 2024 00:20
|
|
|
Unreal’s footprint for working in the editor is surprisingly small, so any moderately powerful machine is fine. If your PC can run the kind of game you’re making (and you’re not making a hilariously unoptimized mess), you can run the editor. I’ve done small hobby projects on a five year old laptop and it was just fine. Is there a particular reason you’re looking for specifications? If you’re just asking if Unreal will run adequately on your existing machine, the answer is “probably yes”. If you’re looking for specs for a new machine, building a mid-tier gaming rig with a big SSD and as much extra RAM as you can afford is a solid starting point.
|
|
#
?
Jan 23, 2024 08:09
|
|
|
Unreal allocates roughly 2.5gb of ram per thread when compiling, and will only use threads if it can reserve enough. So I’d put at least 64gb into anything that’s actually building on a semi regular basis.
|
|
#
?
Jan 23, 2024 11:25
|
|
|
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
|
|
|
Unreal's coding standard using PascalCase for every variable name is really wild to me. I don't think I've ever seen that anywhere else before.
|
|
#
?
Jan 24, 2024 22:25
|
|
|
Rocko Bonaparte posted:Unreal's coding standard using PascalCase for every variable name is really wild to me. I don't think I've ever seen that anywhere else before. Wait til you learn what the F prefix in type names stands for.
|
|
#
?
Jan 24, 2024 22:33
|
|
|
more falafel please posted:Wait til you learn what the F prefix in type names stands for. Isn't it 'F' as in... FEverything?
|
|
#
?
Jan 24, 2024 22:35
|
|
|
Rocko Bonaparte posted:Isn't it 'F' as in... FEverything? Float (I originally thought it meant 'Freestanding' as in anything another prefix didn't cover.)
|
|
#
?
Jan 24, 2024 22:46
|
|
|
https://youtu.be/qtgbKybB4xo Godot's pretty decent. Managed to follow the tutorial, at least. Now to never touch it again because I can't keep a hobby for poo poo ᕕ( ᐛ )ᕗ
|
|
#
?
Jan 25, 2024 01:17
|
|
|
Further Godot glupshittery: I’m a little daunted by scene-driven development. I know it’s intended to be simple and flexible and to just be a very straightforward and generic tree graph representation of any given game, but that doesn’t make it obvious to code and organize. I tried sketching out a scene graph for a Breakout clone, but got lost in the weeds and now I’m all confused. It’s a very open-ended problem and I’m pretty bad at those  For those of you who use it, how do you organize your game pieces and concepts into scenes? Do you make one scene per entity or physical object, e.g: - Ball scene - Paddle scene - Brick scene - Wall scene - Game scene - etc. Do you make scenes per literal or conceptual container, e.g.: - Player scene has-one Paddle scene, has-one Score scene, has-many Ball scenes, etc. - Level scene has-many Brick scenes, has-many Wall scenes, has-one Background scene, etc. - Game scene has-many Level scenes, has-one Player scene, has-one Controller scene, etc. Do you make scenes by scope, e.g.: - Level scene contains all visual scenes (e.g. sprites and tiles) - Sound scene contains all audio scenes (e.g. SFX and BGM) - Controller scene contains all input-related scenes - Game scene contains all scenes I’m pretty used to object-oriented programming so I tend to apply physical metaphors and reach for composition wherever possible, but I have no idea if that makes sense in the context of game development.
|
|
#
?
Jan 30, 2024 00:53
|
|
|
I haven't done any Godot but that impression of the concept like scenes just doesn't smell right. You can probably do everything in the same scene for a breakout game. If you wanted to dabble in scene transition, then put the main menu in another scene. It would blow my mind if it had something conceptually different for scenes.
|
|
#
?
Jan 30, 2024 01:19
|
|
|
Rocko Bonaparte posted:I haven't done any Godot but that impression of the concept like scenes just doesn't smell right. You can probably do everything in the same scene for a breakout game. If you wanted to dabble in scene transition, then put the main menu in another scene. in godot scenes serve as both unity scenes and unity prefabs
|
|
#
?
Jan 30, 2024 01:27
|
|
|
Godot calls scenes what unity calls prefabs (being very reductive, but generally speaking). They happen to also work like what unity calls scenes, but it mostly makes sense in context. Efb!
|
|
#
?
Jan 30, 2024 01:29
|
|
|
I was going to say that apparently my mind is blown, but I am kind of imploding instead trying to imagine how that works.
|
|
#
?
Jan 30, 2024 02:10
|
|
|
Scene is a loving terrible name but I’m not in charge soooo whatever. I’ll just pretend I’m doing graph algo bullshit and call them vertexes in my head.
|
|
#
?
Jan 30, 2024 02:14
|
|
|
Rocko Bonaparte posted:I was going to say that apparently my mind is blown, but I am kind of imploding instead trying to imagine how that works. just think about additive scene loading and then dont worry that you could split the types
|
|
#
?
Jan 30, 2024 02:51
|
|
|
Pollyanna posted:Further Godot glupshittery: I’m a little daunted by scene-driven development. I know it’s intended to be simple and flexible and to just be a very straightforward and generic tree graph representation of any given game, but that doesn’t make it obvious to code and organize. you're overthinking it - the only big advantages of saving branches of the tree as their own scenes is ease of reuse and the ability to load them at runtime. in a single screen game like breakout you could simply have all the game-relevant stuff in a single "game" scene heck, since scenes in godot are just branches of the tree saved to disk you can even choose to make something a scene later if you feel like it. simply right click on a node and save branch as scene and now it's a scene. a lot of the time when i'm prototyping in godot i'll just slap everything together in the same scene and then save out whatever i want to reuse later. it's not really the kind of thing that has to be clearly structured ahead of time, as you can also just move branches around as much as you want putting aside the idea of scenes (which again, are just branches saved to disk) it sounds like a lot of what you're asking about is just how to organize the tree and i have some pointers on that. child nodes inherit the transform (position, rotation, scale) of their parent node so for anything that moves around it makes a lot of sense to group things by what "belongs" to them. as an example let's take a player node
you can also use nodes just to group things up just for the sake of housekeeping. for example here i made a node (Candles) that doesn't serve any purpose other than a container for all the candles in the scene, so i know where all of them are and also i can minimize the branch to make the tree easier to look at  i used this extensively in a pinball game i made which was a single-screen game just like breakout - all the static collision polygons were grouped under one node, all the rollover switches were grouped under one node, etc. i've been using godot for a few years now and can't stop hooting and hollering about it so please ask me anything  i just woke up and i'm a bit scrombled so i apologize if my explanations aren't that great. but just ask!also we've got several godot users over in the other gamedev thread which is a bit less programmer-centric if you wanna check it out https://forums.somethingawful.com/showthread.php?threadid=3506853
|
|
#
?
Jan 30, 2024 06:39
|
|
|
What made scenes click for me was realising that they’re actually just class initialisations made declaratively through the editor. I could programmatically initialise and keep references to Sprite and AnimationPlayer in my Player’s _ready function or just add them as nodes to the player scene. Any OOP concept you want to use can be done with nodes and scenes because they’re just initialised class objects. You can even pass parameters to nodes in the inspector, just like you would for a class constructor. A script on the root node isn’t extending the scene, the scene is an extension of the script. Each scene you conceptualise is another class in your game. @export is just adding your custom parameters to your custom class. The scene tree then just becomes the tree of references that make up the games objects. Don’t think of scene relationships spatially but rather in terms of what references each object is going to strictly need to function.
|
|
#
?
Jan 30, 2024 11:33
|
|
|
Your Computer posted:for example here i made a node (Candles) that doesn't serve any purpose other than a container for all the candles in the scene, so i misremembering know where all of them are and also i can minimize the branch to make the tree easier to look at What would happen if you needed to add other screens like a title menu, a high scores list, etc.? Would all the elements for each unique screen be direct children of Game (like a flat hierarchy)? Would you add new scenes representing each screen under Game, or would you make Game a scene and reuse it elsewhere? quote:i've been using godot for a few years now and can't stop hooting and hollering about it so please ask me anything I’ll stop by sometime for sure - thanks!
|
|
#
?
Jan 30, 2024 18:10
|
|
|
Pollyanna posted:What would happen if you needed to add other screens like a title menu, a high scores list, etc.? Would all the elements for each unique screen be direct children of Game (like a flat hierarchy)? Would you add new scenes representing each screen under Game, or would you make Game a scene and reuse it elsewhere? each of those screens would be their own entire trees saved as their own scene (in this case, in the true sense of the word) and this is where the ability to load scenes at runtime comes in handy - you could make a script that manages game state which is either global (godot calls these Autoload) or the root node which then loads the next scene and unloads the current one, effectively replacing the entire tree with a new one. you can also use this technique within the game itself, for example you can have a gameplay scene that contains all the static bits for the game and then load and unload the maps/stages/levels without reloading everything else
|
|
#
?
Jan 30, 2024 18:37
|
|
|
That works for game screens, though now I’m wondering how concepts and systems that are independent of a particular screen are modeled. What if a Player represents data that’s used across multiple screens? Like how an RPG has the Player’s controlled character on the world map, the Player’s party members in the battle scene, the Player’s inventory in the pause menu, etc. If the Player is generally a child of a given screen, wouldn’t you have to make sure the Player gets moved around the tree when changing scenes? Or if each screen has its own Player, which is the real one? OOP-wise, best practice would say to pass the Player by reference to each screen scene. So the Player would be an independent concept directly under the root, and when instantiating the scenes you’d have to pass it along as a parameter to the constructor. In Godot, it seems like you have to do that via scripting? It doesn’t look like you can wire up object references via the scene editor UI alone… Pollyanna fucked around with this message at 19:35 on Jan 30, 2024 |
|
#
?
Jan 30, 2024 19:25
|
|
|
|
| # ? May 18, 2024 21:03 |
|
|
Pollyanna posted:That works for game screens, though now I’m wondering how concepts and systems that are independent of a particular screen are modeled. What if a Player represents data that’s used across multiple screens? Like how an RPG has the Player’s controlled character on the world map, the Player’s party members in the battle scene, the Player’s inventory in the pause menu, etc. If the Player is generally a child of a given screen, wouldn’t you have to make sure the Player gets moved around the tree when changing scenes? Or if each screen has its own Player, which is the real one? I’d say in this more complex case, your Player isn’t a single class: there’s PlayerOverworldModel, PlayerBattler, PlayerInventory, etc. Each class then behaves differently depending on what scene it’s in, and PlayerInventory can live atop the “screen scene” so it can feed its data to different scenes.
|
|
#
?
Jan 30, 2024 20:31
|
|