|
Ranzear posted:Godot? It doesn't have ... wait they added that in 3.0. I got started with Godot very recently with the 3.0 beta. I haven't used unity in years, and never did much of anything with it, so I was just wondering what made unity worse since it seems like everyone and their uncle are using it. ZombieApostate posted:I think he meant that Unity has some features that aren't very good by default, but have better solutions on their marketplace written by other people which aren't generally free. Thanks, that makes sense.
|
#
?
Apr 7, 2018 02:36
|
|
|
|
| # ? May 12, 2024 02:02 |
|
|
Unity had the first usable mass-market engine with a decent tool set, so it had the whole market to itself for a while and built up an ecosystem of community, assets, infrastructure, talent, etc. which remains one of its biggest advantages. UE4 is trying to enter the same market from the opposite direction, it doesn't have as much of that ecosystem, but it's growing rapidly, it has the advantage of Epic using their own engine, and it's funded by a pretty well-established AAA licensee base, including enough money from PUBG royalties to fund a Scrooge McDuck style money pool. Godot doesn't really have either of that but it does have a really nice workflow and could become very good if it gets some major backing or enough community interest. I'm probably biased, but I used to groan about Scaleform being necessary at all when UI is basically a scene management problem, which games should be good at. Turns out most game tech isn't good at it at all, which is why it needs UI frameworks. Godot is good at it, so it doesn't have a UI system. Overall, it feels less like an engine + editor than it feels like a DCC tool for making games, which is much closer to how I've long felt that an engine should work and it seems like a much more natural solution to the problem. Whether that's enough to overcome Unity's market share or UE4's PUBG/FNBR money printer, I dunno, but it's promising, and it's super easy to get stuff done in it.
|
|
#
?
Apr 7, 2018 05:36
|
|
|
Ugh Scaleform. I came onto a project where the studio clearly didn't know how to use it properly and had vector graphics with a poo poo ton of control points each for even the smallest of things and they were baffled why this was a huge performance problem. I haven't had the opportunity to mess with Unreal's new UI stuff. It looks like it is a tiered system. Slate at the low level and UMG at the higher level. It looks like Slate is even used for all of the Unreal Editor UI but UMG is only used for the in-game stuff. xgalaxy fucked around with this message at 06:34 on Apr 7, 2018 |
|
#
?
Apr 7, 2018 06:32
|
|
|
Me i am using LibGDX and finding it a really nice system,
|
|
#
?
Apr 10, 2018 09:47
|
|
|
xgalaxy posted:Ugh Scaleform. I came onto a project where the studio clearly didn't know how to use it properly and had vector graphics with a poo poo ton of control points each for even the smallest of things and they were baffled why this was a huge performance problem. Heh, in relation to this, think REALLY hard before using bindings in UMG. They look really handy, but they're actually functions called every frame, which given the VM overhead inherent in blueprint functions leads to a ton of performance problems. It's something every team tries, once. UMG has a couple major things I'd like to see them add (masking volumes and some form of cascading style sheet) but I would still suggest that anyone doing UI in UE4 default to using UMG unless you are doing something crazy with the engine. It's well integrated into the workflow, and is powerful enough to do what you want.
|
|
#
?
Apr 10, 2018 20:07
|
|
|
The nicest thing about Scaleform is how if you disable the UI in games using it, odds are you'll improve frame timings by 3-4ms.  Scaleform's VM and GC are really attrocious (and to be fair, so are the abominations our UI programmers come up with sometimes).
|
|
#
?
Apr 10, 2018 21:50
|
|
|
To be fair, UI programming is a loving nightmare.
|
|
#
?
Apr 10, 2018 22:51
|
|
|
we just require our ui artists to make plane meshes in maya and they animate them using the same timeline animation tools as the rest of our game. surprised more games don't do this.
|
|
#
?
Apr 10, 2018 23:06
|
|
|
Suspicious Dish posted:we just require our ui artists to make plane meshes in maya and they animate them using the same timeline animation tools as the rest of our game. Seems like there would still be some tricky parts remaining, like relayouting dirty areas when bound data changes, letting the user interact with the game via gui while keeping the architecture clean, the whole mess of handling a million different display modes in a bunch of languages, etc
|
|
#
?
Apr 10, 2018 23:21
|
|
|
"dirty areas"? what are those? this is a video game, we redraw the entire scene every frame.
|
|
#
?
Apr 10, 2018 23:26
|
|
|
Scaleform was the worst but every other UI system is the worster Just give me a chrome engine and let me use react 
|
|
#
?
Apr 10, 2018 23:27
|
|
|
Suspicious Dish posted:"dirty areas"? what are those? this is a video game, we redraw the entire scene every frame. Billboarding your UI, maybe?
|
|
#
?
Apr 10, 2018 23:28
|
|
|
dupersaurus posted:Scaleform was the worst but every other UI system is the worster There's a few of those around for UE4 (I've personally looked at https://coherent-labs.com/ the most.) One problem we ran into was they were running the webkit (I think it was webkit?) renderer in a separate process. Fine on PC, distinctly less fine on any sort of closed system like a console.
|
|
#
?
Apr 11, 2018 00:32
|
|
|
The Fool posted:To be fair, UI programming is a loving nightmare. Yes, thank you.
|
|
#
?
Apr 11, 2018 00:51
|
|
|
Suspicious Dish posted:we just require our ui artists to make plane meshes in maya and they animate them using the same timeline animation tools as the rest of our game. I'd like to hear more about this actually. Are they laying out "planes" of meshes for every UI element or is it on a less granular level.. like per dialog or per screen? And then I'm assuming you just use that for your UI render target surface. xgalaxy fucked around with this message at 01:02 on Apr 11, 2018 |
|
#
?
Apr 11, 2018 01:00
|
|
|
dupersaurus posted:Scaleform was the worst but every other UI system is the worster https://github.com/ncsoft/React-UMG I'm still learning vanilla UMG though, so I can't speak to how useful or good it is.
|
|
#
?
Apr 11, 2018 01:35
|
|
|
BabelFish posted:There's a few of those around for UE4 (I've personally looked at https://coherent-labs.com/ the most.) One problem we ran into was they were running the webkit (I think it was webkit?) renderer in a separate process. Fine on PC, distinctly less fine on any sort of closed system like a console. Cheston posted:https://github.com/ncsoft/React-UMG Nice, if only I was still in the industry...
|
|
#
?
Apr 11, 2018 01:44
|
|
|
dupersaurus posted:Nice, if only I was still in the industry... As someone wanting to do game dev but currently in web dev... this is cool as heck
|
|
#
?
Apr 11, 2018 02:07
|
|
|
xgalaxy posted:I'd like to hear more about this actually. depends on how the artists set it up -- usually it's one mesh per "movable element". the only other thing we have is a special kind of object that renders text at runtime. we also have a material / shader system and we built nine slicing in that. so they can just scale meshes like they would other game objects and it works fine.
|
|
#
?
Apr 11, 2018 02:19
|
|
|
Suspicious Dish posted:we just require our ui artists to make plane meshes in maya and they animate them using the same timeline animation tools as the rest of our game. That's basically what's so good about it, it just lets you manipulate the scene with the same degree of ease as DCC tools do, at which point the 2D object management stuff just becomes usable as a UI system for free.
|
|
#
?
Apr 11, 2018 06:18
|
|
|
OneEightHundred posted:Godot's animation system lets you key arbitrary object attributes on a timeline, so it just straight-up gives you the typical DCC tool workflow.
|
|
#
?
Apr 11, 2018 16:35
|
|
|
Serialization. This is probably a dumb question, but here we go. I'm trying to write functions to save and load my game state, and I get the concept of serializing objects. What I don't get is how to handle references properly. For example, I there are Fleets in my game. These contain: code:Nice tools like JSON.net seem great at taking an object and serializing it, and I can see that I can tell it not to serialize something, so I can avoid a simple object containing every object it references. But what I'm not sure about is the best way to rebuild that connection when I deserialize. If I didn't serialize those referenced objects, that reference won't survive the serializing process. It seems like I should be replacing the reference with some kind of unique Id at the point of serialization, like a string or something, and when I unserialize, turn that string back into the original object reference. Is that a reasonable approach or have I got this all wrong?
|
|
#
?
Apr 12, 2018 09:55
|
|
|
Dirty posted:It seems like I should be replacing the reference with some kind of unique Id at the point of serialization, like a string or something, and when I unserialize, turn that string back into the original object reference. Is that a reasonable approach or have I got this all wrong? That's a reasonable approach I think. To some extent you can also restructure your data, like in your example if your serialized StarSystem contained a list of Fleets instead of Fleets containing a StarSystem, you could avoid duplicate references (then in a post-serialization step, set the references on the fleets how you want them during run-time). I use protobuf.net to serialize my datastructures, and it allows you to pass a decorator "AsReference=true" which makes protobuf.net internally keep track of this thing and sets up the right shared references on deserialization. It scares me a little though, and I prefer structuring my data so that every instance is referenced exactly once. Mata fucked around with this message at 10:25 on Apr 12, 2018 |
|
#
?
Apr 12, 2018 10:22
|
|
|
Dirty posted:Serialization. if only .net had a built in structure for unique identifiers that would perform and behave better than strings
|
|
#
?
Apr 12, 2018 13:41
|
|
|
No need to be snarky, theirs is a valid question on how to properly save and load their list. You'll want to have your List<ShipItem> not be serialized and instead have a List<Guid> that properly stores or loads the ShipItems when saved or loaded.
|
|
#
?
Apr 12, 2018 15:35
|
|
|
Mata posted:That's a reasonable approach I think. To some extent you can also restructure your data, like in your example if your serialized StarSystem contained a list of Fleets instead of Fleets containing a StarSystem, you could avoid duplicate references (then in a post-serialization step, set the references on the fleets how you want them during run-time). leper khan posted:if only .net had a built in structure for unique identifiers that would perform and behave better than strings Polio Vax Scene posted:No need to be snarky, theirs is a valid question on how to properly save and load their list.
|
|
#
?
Apr 12, 2018 16:56
|
|
|
This isn't an easy problem and depends on the language. Two ways to deal with this are handles and 2-pass loading. With handles, you don't store references to things directly, but rather store references to a proxy that points to the actual object. Doing that can help with some other things too, like deleting objects, since you can just invalidate the proxy instead of having to track down all of the dead references or use events. When deserializing, you can just deserialize the handles and make an ID-to-object table and then make the proxies all point to any live objects after everything's loaded. The downside to using handles is that they're more prone to annoying mistakes if an uninitialized handle and a handle referencing a dead object are distinguishable, so it's probably best to use a struct "ProxyReference<T>" wrapper or something so the compiler will at least warn you if you try to compare it to null. If you want to keep actual references, then you can use 2-pass: Create all of the objects and build the ID-to-object table, then deserialize the object properties. (There's a way to do that in one pass too by queuing up unknown objects in the same order that they were serialized, but it's more complicated and not very useful). The next important piece of all of this is making sure you have some way to distinguish between references to static game data and what references mutable game state, and to do that, you need some uniform way of referencing game data (resource IDs, etc.), so plan for that in advance. OneEightHundred fucked around with this message at 18:23 on Apr 12, 2018 |
|
#
?
Apr 12, 2018 18:09
|
|
|
Is there a tutorial, book, series that teaches making a roguelike in any language?
|
|
#
?
Apr 15, 2018 20:27
|
|
|
Although it's not a straightforward set of tutorials, take a look at the development articles here. It seems to have a decent mix of high-level design articles and deeper dives on specific topics like time unit management. I also had this article saved, which goes into a few things to do with turn-based update loops.
|
|
#
?
Apr 15, 2018 20:57
|
|
|
Staggy posted:Although it's not a straightforward set of tutorials, take a look at the development articles here. It seems to have a decent mix of high-level design articles and deeper dives on specific topics like time unit management. Thanks! I'll take a look at these!
|
|
#
?
Apr 15, 2018 21:33
|
|
|
Staggy posted:I also had this article saved, which goes into a few things to do with turn-based update loops. That guy's stuff is awesome. He works on designing the Dart language at Google. He wrote the Game Programming Patterns book. He is writing a new book about compilers and designing an interpreted language. He also wrote his own hobby language called Wren. And finally, he likes to toy around with Roguelikes. I haven't read it, but I'm sure whatever he writes about Roguelikes is insightful.
|
|
#
?
Apr 16, 2018 01:43
|
|
|
OneEightHundred posted:This isn't an easy problem and depends on the language. Two ways to deal with this are handles and 2-pass loading. With handles, you don't store references to things directly, but rather store references to a proxy that points to the actual object. Doing that can help with some other things too, like deleting objects, since you can just invalidate the proxy instead of having to track down all of the dead references or use events. When deserializing, you can just deserialize the handles and make an ID-to-object table and then make the proxies all point to any live objects after everything's loaded. The downside to using handles is that they're more prone to annoying mistakes if an uninitialized handle and a handle referencing a dead object are distinguishable, so it's probably best to use a struct "ProxyReference<T>" wrapper or something so the compiler will at least warn you if you try to compare it to null. Thank you, I'll have a think about those approaches. I'm glad to say that I already have a consistent and solid system for static game data, so it's easy to boil those down to reference ids in the game state.
|
|
#
?
Apr 16, 2018 11:22
|
|
|
I don't know much about game/graphics development, but I've got a use case at work that I think might call for Unity and just want to verify that it may be a good option before wasting too much time chasing down a hole for nothing. I work for a manufacturing company and our team is in charge of putting out tools, HMIs, and visualization platforms for our operators and laborers that work in a plant. I'm restricted to using C# for development purposes (less I become the only one capable of maintaining it) and have been put in charge of our next product. It needs to be a touch screen, interactive HMI that's going to be mounted in some heavy equipment. Everything we've built so far has been in WinForms or WPF but the specifications and requirements for these interfaces continue to increase in complexity every time we put out a new tool so I'm thinking that maybe a game engine might be better suited for what we're doing? Something that's more than a menu driven desktop application but not quite a full on game. I'm thinking Unity just because of the C# requirement, but I don't know the first thing about graphics development outside of desktop apps so if that's overkill I'm open to other options. Basically I'm just looking for something to develop highly graphical custom 2D interfaces.
|
|
#
?
Apr 16, 2018 18:15
|
|
|
Portland Sucks posted:I don't know much about game/graphics development, but I've got a use case at work that I think might call for Unity and just want to verify that it may be a good option before wasting too much time chasing down a hole for nothing. Unity will work for this use case, assuming your runtime is at least as powerful as a consumer netbook/tablet. Do a google for unity canvas ui for some tutorials. Its some approximation of drag/drop.
|
|
#
?
Apr 16, 2018 19:45
|
|
|
Seconding the notes above on Godot 3.0, but adding a question -- Coming from an enterprise perspective, I've found Godot doesn't die to version control with `git`, but there's still a lot of point-click-&c in the interface. As an impatient person, this drives me crazy but I'm trying to stick with it on the basis of cross-platform dev on the quick. I really want to use something like libGDX where I can develop a game on the JVM, but I've found virtually no tooling support for builds / getting started -- the docs are a mishmash of what they were doing a few years ago with maven and doing now with gradle... Am I the only person with this kind of thought process? Am I terrible? I have to presume so. ( edit : I'm only interested in 2D development in this context )
|
|
#
?
Apr 17, 2018 04:36
|
|
|
I'm trying to build a Quarth clone for funsies and am kinda stuck on the logic that determines when a set of combined shapes equals a rectangle. For those of you not familiar:   Has anyone built something similar and would have some insight?
|
|
#
?
Apr 17, 2018 05:50
|
|
|
Portland Sucks posted:I don't know much about game/graphics development, but I've got a use case at work that I think might call for Unity and just want to verify that it may be a good option before wasting too much time chasing down a hole for nothing. I know a guy who worked on automotive entertainment systems and they used Unity for their UI, so it's not a stretch.
|
|
#
?
Apr 17, 2018 06:08
|
|
|
nolen posted:I'm trying to build a Quarth clone for funsies and am kinda stuck on the logic that determines when a set of combined shapes equals a rectangle. Assuming you have collided with a square on the board: Flood fill around the square to find a "bounding box", and then do a separate loop over the bounding box, making sure that each box is filled in.
|
|
#
?
Apr 17, 2018 06:19
|
|
|
nolen posted:I'm trying to build a Quarth clone for funsies and am kinda stuck on the logic that determines when a set of combined shapes equals a rectangle. I've not done this before but I'll take a stab at it. Uggh, detecting both independent rectangles and combined rectangles makes this a lot harder. You probably want to check for combined rectangles first to avoid ticking off the players. To get those kinds of graphics, I'm going to assume that each cell tracks if it is filled in, and some mechanism for indicating which shape it is part of; pointer, integer flag; something. This algorithm relies on the fact that rectangle's width is consistent across its height. 1) Check for combined rectangles. a. the active row and column match the ones for the cell that just got filled in. b. find the width of the rectangle by checking to see if the cells to the right and left on the active row have been filled in until you find the first blank spot. This is now your reference width. C. Check up and down the active column to see if they have the same width until you find the first blank spot up and down or you find a row with different width than your reference width. O(maximum column * width of active row) D. Verify the rectangle doesn't have any bits sticking off that belong to the included shapes. (Yuck, fortunately, you only have to check for bits sticking off the top and bottom since we've already checked the sides.) E. Remove any shapes with sticking off bits as per D and check to see if you still have a rectangle. e1. If you do have a rectangle now, great, you're done. e2. if not, go back to D and repeat until you have no included shapes. (fortunately this set will never be large in modern computer terms) It's also a pretty small space, you could just brute force it and build possible rectangles for every square similar to match 3 game hint algorithms.
|
|
#
?
Apr 17, 2018 06:30
|
|
|
|
| # ? May 12, 2024 02:02 |
|
|
nolen posted:I'm trying to build a Quarth clone for funsies and am kinda stuck on the logic that determines when a set of combined shapes equals a rectangle. As mentioned, you can basically do a flood fill within the set of squares that are part of some shape to find the set of combined shapes. To pseudocode badly: 1. Add the square you just added to the board to a set. 2. Add all unvisited neighboring squares of the square you added to a queue. 3. Visit the next square in your queue -- If the next square is part of some shape, add it to your set and its unvisited neighbors to your queue -- If the next square is not part of some shape, just mark as visited. 4. If you've got more squares in your queue, back to 3. 5. Once your queue is empty your set will contain all squares in the combined set of shapes that your new square is a part of. Test if this set is equal to its bounding box (you really only need to test that the number of squares in the set == number of squares in the BB == BB's width*height).
|
|
#
?
Apr 17, 2018 06:51
|
|
