UDK, we have a problem!

When you used to program you used to some structures of data. One of them is Map (or Dictionary if you prefer this name). Actually if you look into udk documentation you will find implementation of it. So you are happy, but if you decided to use blueprint only you will loose your happiness quickly :) There is no such structure for BP. WHAT?! This is mean! But true, so be warned dear reader. But ok we have a lot years of experience not a fucking problemo! We use proper combination of arrays or custom objects and we can create any substitute missing map. But, there are more sad news... If you want to have some data taken from outside of project you can use CSV or JSON encoded table. So it's quite straight forward: 

• Define structure of data (any primitive types can be used)
• each structure will be one row in your CSV (or one node in json)
• you import this as a data table.

Great! Now you can put all your dialogs and other things to this. BUT! There is one BIIIG gotcha! You can't hold reference to data table. So you can't make variable to which you connect Data Table and pass this value to other functions/macros. And this is pain. It leads you to situation when in many places you need to put switch and depending on some condition you redirect data fetching from different data tables. So after some thinking I made some workaround: on the beginning of episode/chapter I use switch to select proper data table, and then I iterate through it and copy it into ordinary array of objects. From this moment you are free to pass it as reference anywhere you whish. Of course this leads to duplicate memory usage for those data but since this is some lightweight object it will consume less memory then single texture.

The last thing which is worth mentioning for java/c# developers is that UDK works in word of C++. So "normal" call is through COPY nor REFERENCE this is painful when you start to use structures. I spent few hours searching for bug before I realised that I'm dealing with copy... 

I still need to research life cycle of object. UDK has some kind of garbage collector which works in way which I don't understand now. So I've no idea when object is disposed. When I discover this I probably write few words on this blog.

And the last thing... Well debugging of BP inside UDK, yes I think I can call it hell...