This isn't a bad talk. But some things to note for anyone else. When talking about cons of make custom tools in editor. They say that one is that they are messy and can be hard to use. That is completely false, there is no reason that a tool can not be very clean and usable that comes down to having good UX and UI. And the end someone asks about mistyping string keys in by mistake. Something that I found is a good solution for this is to have a list of all the string keys, and make a dropdown menu with a simple search that you selected them from. It is pretty simple to do, and removes any chance of mistyping.
@@kinguitar1987 I use Odin, it saves a huge amount of time developing and testing. Unfortunately UI's can very quickly start to crawl, even quite simple ones.
A good solution is to not use string but use hard references where they make sense. This system is over engineered for what it needed to do and thus makes it mare unwieldy to use.
06:33 he says that dictionaries becomes slower the more entries it has, this is completely wrong, no? The only expensive operation in a dictionary is if the underlying array needs resizing, which you should be able to avoid for cases like this?
A dictionary still works as a book in the real word. You have to open the book every time and need to start looking for the right page and position on this page. So yes you can search really fast in a dictionary because it is ordered but if you do it with to many values you can not really do it every frame.
For business applications it's not a problem, but for games it can be a big issue when doing lookups every literal fraction of a second in a (or multiple) multi-thousand-record dictionary
@@robbydomino What ? Sorry, but that is wrong. You dont need to start looking for the right page and the position. A Dictionary (= Hashtalbe ) is the fastest Datastructure to look up things. Ordering doesnt matter. The Lookup-position is computed by a function. You have a function , where you put your lookup-key as argument and the function computes! where in the datastructure you find the corrsponding value to the key. So you dont have look through the Datastructure in any way, you instantly know the memory address where you find your value after computing the value of that function.
The idea of how the system works is obscured by the amount of time spent talking about implementation details. It would have been clearer to show some boxes-and-arrows diagrams instead of screenshots of your internal tools.
So awesome that Elan Ruskin had the first question, knowing he inspired the design of dialog
Last 10 minutes was invaluable! Especially as someone who has plans for a game with a lot of strings.
Wow. I had no idea the dialog system was so robust -- this talk spurred me to buy the game.
Nice video, Boolean switches work so easily. I use bool combined with activate object, and trigger events all the time
This isn't a bad talk. But some things to note for anyone else.
When talking about cons of make custom tools in editor. They say that one is that they are messy and can be hard to use. That is completely false, there is no reason that a tool can not be very clean and usable that comes down to having good UX and UI.
And the end someone asks about mistyping string keys in by mistake. Something that I found is a good solution for this is to have a list of all the string keys, and make a dropdown menu with a simple search that you selected them from. It is pretty simple to do, and removes any chance of mistyping.
I think they are refering to Unity Editor custom tools are hard to build, but if you use Odin, it gets pretty easy.
@@kinguitar1987 I use Odin, it saves a huge amount of time developing and testing. Unfortunately UI's can very quickly start to crawl, even quite simple ones.
A good solution is to not use string but use hard references where they make sense. This system is over engineered for what it needed to do and thus makes it mare unwieldy to use.
Why anyone would downvote this is beyond me.
amazing talk! thank you from Brasil!
I want to know more about the party. :D
For now Firewatch will suffice though.
Super interesting! Thanks for the talk!
Clearly the turtle should've been called "Turt Reynolds".
I couldn't find any info about this magpie cms tool and unity integration. Can anyone help me?
I think it's an internal tool.
It's Patrick (One of the speekers of this talk) that built it.
These are so freaking cool I swear!!
Good game. Interesting talk.
27:15 Why fear the interrobang‽
whats the link to the magpie site?
ended up almost falling in love with delilah cuz of there system :)
06:33 he says that dictionaries becomes slower the more entries it has, this is completely wrong, no? The only expensive operation in a dictionary is if the underlying array needs resizing, which you should be able to avoid for cases like this?
A dictionary still works as a book in the real word. You have to open the book every time and need to start looking for the right page and position on this page. So yes you can search really fast in a dictionary because it is ordered but if you do it with to many values you can not really do it every frame.
On the other hand it seems that these key-value pairs are static, so from that perspective access should always be constant..
For business applications it's not a problem, but for games it can be a big issue when doing lookups every literal fraction of a second in a (or multiple) multi-thousand-record dictionary
@@frankhaugen this all depends, the fact remains that the data structure itself doesn't grow slow as indicated though
@@robbydomino What ? Sorry, but that is wrong. You dont need to start looking for the right page and the position. A Dictionary (= Hashtalbe ) is the fastest Datastructure to look up things. Ordering doesnt matter. The Lookup-position is computed by a function. You have a function , where you put your lookup-key as argument and the function computes! where in the datastructure you find the corrsponding value to the key. So you dont have look through the Datastructure in any way, you instantly know the memory address where you find your value after computing the value of that function.
The idea of how the system works is obscured by the amount of time spent talking about implementation details. It would have been clearer to show some boxes-and-arrows diagrams instead of screenshots of your internal tools.