Dragon Age 1/2 engine porting to Unity

the project repository:
https://github.com/dhk-room101/YetRPG

I'm physically and visually challenged( quasi-disabled computer related), with a lot of free time and an active mind, but not enough able time. anyways, in my limited able time, to keep my mind occupied I do stuff, mostly reverse engineering, as is challenging and fun, plus statistically speaking reverse engineering requires a lot of thinking and less eyes/hands using, which mine are mostly useless. I'm using voice recognition software to interface with the computer, that solves the lack of hands usability issue, for the eyes issue, I currently don't have any work around except high contrast, big fonts and good memory

Anyways, enough about me, let's talk about why I'm here: as I mentioned I randomly do stuff to keep my mind occupied and in the past few months I wanted to see if porting the engine used in Dragon Age 1/2 is doable. Which it is, although the premise is based on an invalid inference: both Bioware NSS scripting and Unity C# scripting are IL and C like.

So awkwardly and slowly I did the following:
1. Copy/paste of the _h classes from Dragon Age 1, available from their toolset, into Visual Studio 2015 where the unity integration enabled
2. Similar for _core classes
3. Finally both Dragon Age 1/2 have a script.ldf which is just a middleman in between the NSS and their proprietary engine
4. I migrated some Excel files from the original game into XML via CSV, if you browse the code you will see my approach

So in my case I made a class where I dumped all the directives found in script.ldf from Dragon Age 2, and updated the syntax from _h and _core files from Dragon Age 1 if/when needed. For example, Dragon Age 2 uses 'ref' similar to modern C# whereas Dragon Age 1 doesn't. Also because the original directives from script.ldf come with very good comments, it was just a matter of writing my own C# code to complete the missing ingredient which in Dragon Age 1/2 exists in their proprietary engine.

Of course, because of the state of my health, I couldn't write C# code for all the directives, but I did so for enough of them to illustrate my current game design intentions. Regardless, there is enough code ready to prove my point, which is porting to unity. I personally did this for two major reasons:
1. educational, for me because I'm not a programmer(in early 90s I took a Pascal class in high school though), and for others because it's such a good piece of software that can be used as an insight of how to do things the right way when developing an RPG
2. To keep my mind occupied because unfortunately it requires a high degree of empathy to understand what I'm going through daily in chronic pain and useless body, although unfortunately for me the mind seems to be operational/active, and watching TV doesn't do anything for me

Finally, one of the main reasons I decided to make this project public is that I'm tired: imagine trying to run with heavy weights around your ankles, you probably are able to move forward but at infinitesimal speed, and there is no efficiency from the input of energy required to move compared to the output of velocity.

Here is what I got so far
https://onedrive.live.com/?id=408CADBD12872CD5!105&cid=408CADBD12872CD5&group=0
the project nickname is: 'yet another RPG', that's why it's called yetRPG

I cannot use Github client because it's all white color and my eyes explode in an instance, and I didn't find it in me to deal with it for now, maybe later when I would feel better

What I expect: the community to use this repository to learn, and also I wouldn't mind if there is some willingness to help along and move this forward

It took me about an hour to write this, and it's unlikely I can afford to have a strong online presence, but if you live in the bay area maybe we can hang out, I spend most of my time confined to a small room though, but for zoon politikon purposes I'm willing to make an effort and go outside

 

Well gosh I don't know what to say but welcome and nice work! I am not able to chip in at this point but it certainly seems you've bitten off quite a bit to chew.

You might also want to look into Unity usergroups in your area, and see if any of those folks would have an interest in this type of a deep-porting plunge approach.

Either way, best of luck with your situation!

 

well, today I uploaded a repository
https://github.com/dhk-room101/YetRPG

The current functionality includes: parsing the original XML files and creating placeables and creatures: such as player, NPC, waypoints and add them in the scene at position/rotation as defined in the original Demo Module from Dragon Age Toolset as in the original game, each new entity gets its script attached to it, i.e. creatures use creature_core script file, player uses player_core, area uses area_core, etc., or they can all get a custom script

For example: a new NPC has custom_script as its starting point to handle events, and if there was an event not handled in its custom script, then it gets automatically redirected to creature_core, and if once again the event doesn't get processed in creature_core, then it gets redirected to rules_core, following the exact same pattern as the original Dragon Age developers…

take a look at the picture below, it will give you a better idea of what I have in mind. My goal is to focus on functionality exclusively, content/how things look is not the priority. The final goal is to have a ready-made RPG framework in Unity



color codes for the picture
blue sphere: player
Gray sphere: neutral NPC
magenta cones: placeable
yellow cubes: waypoint

All of these objects were created on the fly and repositioned according to the information parsed from the original Demo Module from Dragon Age Toolset.

To do: expand AI, and changing levels, eventually some dialogue implementation

 

update: switching areas currently works fine, if you click on a placeable with area tag and waypoints tag set, the engine correctly removes the previous objects and creates new objects according to the new area XML parsed objects, then the camera and player jump to the correct waypoint

I'm currently working on auto scaling the player and NPCs, according to the data parsed from the original Dragon Age tables, the 2DA/GDA files if you are familiar with those, in my case I converted them to XML. For example, my player's class is 1, which according to the Dragon age 2DA entry in cla_base.gda is a warrior, and it's base health is 100, so currently the engine parses all this information, and correctly sets the properties on my player object in unity.

Stay tuned for more updates soon

 

the event struct is functional and follows Dragon Age 2 using 'ref'. Currently in my tests the player sends EVENT_SPAWN, which triggers CharGen_initialize, and I bypassed the original command that opens the character generation menu, instead uses values parsed from the XML. Which is perfect, because after manually triggering EVENT_SPAWN, everything else that comes after uses the already existing code from Dragon Age.

As of now, character appearance, base attributes and tactics are correctly set in code. I had fun working on properties, I had to write from scratch handling properties types: simple, depletable, derived, etc. and attribute value types: base, modifier, total, etc. I also added some basic clamping conditions for depletable properties (health and mana)

I'm currently working on creating an EFFECT struct, as required by the original Dragon Age scripts. I will also use 'ref' for the structure, I'll update when I'm done, may take some hours/days due to voice recognition software limitation and the needs to manually update the original Dragon Age Origins scripts to use 'ref'

Stay tuned…

 

Just noticed this thread. Welcome to the community and I think this is a great task! I absolutely love all the Dragon Age games so I'm very interested in what you're doing.

Thank you for sharing your work so far. I'm very curious to see what you've done so I'll download the project and take a look around.

On the note of github being too bright, you may be able to use some webbrowser plugins to help restyle the colours - something like this (warning: it's a github link itself but it contains instructions for dark styling).

Good luck with the project!

 

the effect struct is now updated. I'm currently having fun with creating floating text, as I mentioned in my previous post, I simply manually triggered spawning, and then all the code like a cascade is going through the original Dragon age, and when it hits the LDF directives, then it's time for me to write my own code. And currently character generation wants to display some floating text, so I have to fill in the blanks, I should have some updates soon

@CWolf, thank you for your comment and support. Currently GitHub is not the problem anymore, because I'm using the integrated plug-in with Visual Studio 2015, which already has a high contrast theme. The repository you downloaded I think has only switching areas correctly, the rest of the work I did not upload yet, I want to have some sort of functionality without any errors ready before the next online update.

Also,@Kurt Dekker, thank you for liking all my posts

 

YVW! I think I just appreciate good reverse engineering, particularly when the engineer is really having a good time, which you clearly are!

 

the floaty display now works fine, it displays with the correct color and floats up on the screen while slowly disappearing. I even use the original Dragon Age Origins font, for complete experience
The online repository was also updated just now, feel free to take a look and poke around

Few notes, before I forget, just for transparency and brainstorming purposes:
the original scripts seem to be heavily relying on reflection, so for ease of use and porting I kept the same design pattern.
Also, the original design has the most low-level directives blank(found in the LDF file), with wrappers and other utility classes in between custom scripts and the directives. In my approach, I'm doing my best to use the same design, but it's possible that sometimes I can't find the middleman in the thousands of lines of scripts, so I may redundantly write my own. For example, initially for area transition I used my own custom code, but eventually I found UT_DoAreaTransition function that works much better, is more robust and complete.

the main reason I think this project has merits, is that Unity keeps evolving, as opposed to static closed source engines, imagine Dragon Age Origins and any other RPG taking advantage of DirectX 12 or above, and this project aims to give people a ready-made functional framework that they can learn from and use hand-in-hand the evolution of Unity rendering engine and their own visual resources…

anyway, I am very tempted to work now on a basic dialogue interface, I plan to use Dragon Age 2 style, I don't think I mentioned this before, but last year I wrote a Dragon age 2 conversation viewer, so I am somewhat familiar with the format, and besides it's prettier than the linear Dragon Age Origins style .

Stay tuned

 

It is really cool to follow along with your progress, I'm subscribed to the thread because this is very interesting. I hope you enjoy your journey

 

Awesome progress @room101. I'll take a look at the updated code =).

I can imagine it's a huge task to hunt down all the scripts and find the right one you want to plug in. Really awesome reverse engineering! I'll take a peek at the conversation viewer too.

 

thank you all for comments and support!

while contemplating the existentialist dilemma of a conversation interface, I realized that game states changes are required, and in the original Dragon Age it appears that said game states are triggered in their proprietary engine. Which is not the issue per se, but I'd like to think about it for a bit before I jump into the conversation interface.

One step I took was to write a simple parser against the original scripts repository( 2500+ scripts) and get all the "case EVENT_*", after that my working assumption was that the most important classes are the *_core, so I looked under the hood to see which core classes handles which events types.

This is how I learned that the game states changes are handled in module_core class. For example
case EVENT_TYPE_GAMEMODE_CHANGE:
case EVENT_TYPE_DELAYED_GM_CHANGE:
case EVENT_TYPE_SET_GAME_MODE:

Funnily enough I was thrown off the scent by an event I found in module_core related to dialogues
case EVENT_TYPE_CREATURE_ENTERS_DIALOGUE:

As it happens, the above dialogue related event is not used at all, instead the dialogue for creatures is handled in rules_core
case EVENT_TYPE_DIALOGUE:

Anyways, writing the parser was a good move, because I can see now in one glance a group of events handled by core classes in particular, and it helps with extrapolation and future design

I should have an update in the next few days or so, but I wanted to let you all know that I'll spend the weekend in quiet existentialist extrapolation…

 

Why... I was doing this JUST the other day!

 

over the weekend I managed to implement some basic games state changes, along with a parser for dialogues.

Now it's time to implement the basic visual interface for the dialogue. One idea I have for a proper dialogue line positioning along with displaying the correct action icon( friendly, sarcastic, angry, etc.) is to append 2 more characters at the beginning of any text line to be displayed, something like "0c let's be friends", where 0( from 0 to 5) reflects the position on the dialogue we, starting top right going clockwise and C is icon number 12(c hexadecimal equal 12 decimal), and keeping the number of icons needed in hexadecimal range for only one character (0-f). This way we can keep using the original Dragon age toolset dialog editor, and just add those two extra characters at the beginning of a text line, and the parser would take care of the rest

anyways, I just realized that for some reason the GitHub plug-in in Visual Studio didn't upload any of the code or essential files, I have no idea what exactly is happening, but after poking around several times, I didn't figure out how to actually add the code, and unfortunately, me being challenged doesn't help, there may be a solution that I can't see (pun intended ). Let me know if you have some challenged people friendly alternatives.

An example of why it's possible I can't see

above is the toolbar for the quick reply text box in this forum. because I have/need high contrast enabled, no icons are being displayed, whereas on the normal environment, for example you at home can see them just fine.

Well, enough complaining…

Stay tuned

 

I eventually installed the github Windows desktop client and deleted the old repository and upload the new one
https://github.com/dhk-room101/YetRPG

this time all the code is there: https://github.com/dhk-room101/YetRPG/tree/master/Assets/packages/core/scripts
take a look and see if you can make heads or tails out of it
if you have questions about the code, let me know. I'll try and updated regularly, I'm using a UV film behind my regular glasses, this way I can survive the GitHub white background for few minutes

the current repository can be fully downloaded and directly opened in unity 5.3.1, here is the path to the starting scene
https://github.com/dhk-room101/YetRPG/tree/master/Assets/modules/single player/scenes

if you look at the code, the most important custom class is this one: https://github.com/dhk-room101/YetR.../scripts/engine/header/Engine.ldf_engine_h.cs
This file is where I write the custom code to complete the original directives. if you're feeling adventurous, you can open the above file and search for DisplayFloatyMessage function, as an example of how in the original blank direction, was turn to into a full complete function…

anyway, I'll go back to the conversation implementation, my focus would be text and choices, plot flags and such, no animation or camera movements

 

Thanks for all the effort on getting the up-to-date files in there. I'll definitely go through them when I have a few minutes spare . I'll let you know my thoughts.

 

below is a test for the conversation, it follows the modern Dragon age 2 and Inquisition style. As I previously mentioned the first two characters in the text to be displayed represent the line position and the icon to be displayed when hover over. The example below is not complete, but I wanted to show visually what I had in mind.



I'll update when I have a complete conversation system. the good news is that once implemented, the original Dragon age toolset conversation editor can be used for elaborate dialogues, and just export to XML and use them in unity...

 

quick update: the correct flow of the dialogue is now complete, including lines exchanging between player and NPC based on player choices, changing text color when mouse hovers over, also each line displays the correct mood icon, and dialogue lines display in the correct wheel position. The picture below is a pale example . Also keep in mind that the line position and the mood icon is somewhat random, I want to prove functionality at the backend, how pretty or accurate it looks is not the priority…

now the next milestone is implementing plot conditions/actions, and we are done with dialogues for now. Currently I don't plan to look into cinematics and audio, but plot conditions/actions are vitals in the flow of an RPG

 

okay, the conditions and actions work fine, at least in my basic tests, clicking the mouse with the voice is not as easy as it sounds
one thing that we can do, we can have a volunteer to download the project and record 30 seconds of dialogue flow, to show how it's working especially how selecting a specific choice to do or not do the quest makes the NPC start with a different dialogue line next time a conversation is initiated. And then we can upload the video on YouTube and share it here. the online repository was updated to include the latest changes. The project currently uses unity 5.3.2
if you volunteer, please make a statement here in this thread, and then contact me in private.
If no volunteer, I'll try to record myself in the next few days.

 

I realized there was one major missing ingredient that I forgot about related to conversations: the script associated with the plot. Related to the script was a very specific function that is needed: getting the 'defined' flag value
example: the main plot as parsed from the original toolset is called demo000pt_main.plo
This plot has a script associated with it, with the same name: demo000pt_main.nss originally, ported to demo000pt_main.cs
in this script there are two major branches:
-what happens when regular flags are being set( start to fight, add an item to inventory, etc.), and
-the only correct way to get a 'defined' flag, which basically is the logical result of multiple regular flags operations
for example, to loosely quote the Dragon age toolset wiki:
regular flag: have the eggs true/false
regular flag: have the frypan true/false
regular flag: have the fire true/false
defined flag: ready to make an omelette= eggs && frypan && fire
if all regular flags are true then defined flag returns true as well, otherwise false

Now this plot script feature is implemented, the engine now correctly detects the plot name, searches the available scripts for one that matches the plot name, adds it as component, and correctly sets/gets regular or defined flags as needed.

stay tuned…

 

this is a basic example of how it works. Notable features:
-the dialogue is parsed from the XML directly exported from Dragon Age Origins Toolset
-the dialogue correctly displays conversation like or just simple ambient lines, for example the last line is an ambient line, and it simply floats over the NPC
-it correctly uses plot conditions/actions and plot associated script, including correctly getting/setting regular and defined flags
-in the example above, the name of the plot flag being set through plot actions selected in conversation can be seen floating above the player as an example
-also, after the player talks to the barkeep( which sets the correct flag to true), next time when the conversation is initiated, the correct branch is being displayed( the one that checks the defined flag of "the quest being accepted")
-I tested it in the main area(' wilderness'), then I transitioned to 'Tavern' area, it correctly worked as intended, displaying dialogue lines after computing conditionals, so it's time to move on to other things, such as triggers

 

This is very inspiring, keep up the good work! It is very hard to find anyone to actually help with any project. I wish I could help but I already took on a big project.

I will for sure keep my eyes on this thread over time! I tried to google quasi-disabled so I can understand what this means more, and google is not helping me out much here. Are you able to send a link or description so I can learn more about this?

 

@Azmar Quasi-disabled is an expression I use to convey that although technically capable to use senses and limbs like a healthy person, their usage comes associated with various degrees of chronic/acute pain, which triggers the normal response of survival instinct to avoid their usage, therefore rendering me for all intents and purposes incapable of normal usage.
As an illustrative example, imagine that you are thirsty and you have access only to a cup of hot water that never cools down. Your set of choices are quickly reduced to: pain from dying of thirst or pain from burning your mouth/esophagus. Either way, there is pain... And because this is a daily occurrence, the existentialist dilemma is pretty obvious, I hope

Anyways, back to our project: I implemented basic triggers, including visually creating a mesh at runtime from a set of vertexes parsed from the area XML, and of course I gave it the green color similar with the color the trigger gets in the Dragon Age Origins Toolset, see picture below


Now, I realized that I got to a very important milestone: commands, more specific issuing them, what type and what circumstances. The reason is that commands are vital in AI evaluations, although in my case it started with a simple "move to object" command, that is when I click on a placeable that is not in my immediate vicinity, the player should first move closer to the target before initiating the "use object" command. So for the next few days I hope I have a functional command framework

 

ok, a basic command framework is in place. I also implemented basic movement, and most importantly I now handle pretty much everything through commands and events that call the necessary functions.

Example: say I click on the placeable.
1. Is it out of reach yes/no. If yes initiate command move to object, and queue up command use
2. Once in proximity, initiate command use
3. Go through a switch, and eventually find that said placeable is used for area transition, so fire an area transition event

or, another example: say I click on a creature
1. Is it out of reach yes/no. If yes initiate command move to object, and check to see what possible command should be queue up : if creature is neutral or friendly and has conversation, then command start conversation is used
2. After command move, if the queued up command is conversation, go through the motion and initiate the conversation engine

I also implemented triggers, in this example the trigger initiates a conversation, which in the video example above inevitably leads to the barkeep team turning hostile( changes color to red)

Now it's time to look into some combat logic. The less than good news is that I put a lot of pressure on myself in these past few weeks, and my body is really feeling it, and I may need to slow down. replace 'may need' with 'have to'…

 

success. Done and Done. Basic combat is now functional.


I gave the characters a sword from DA:O-T( Dragon age origins toolset), and connected the few dots required to bridge the porting to the combat engine, and everything else fell beautiful in its place, and I watched the logs how the health is being depleted, I saw in the logs how once the health is zero, the death effect is being triggered, and so on. With a little bit of imagination and effort DA:O-T can be used for pretty much everything and then export to XML and use it in unity

I am done with this project. I finished what I set out to do. There is interaction and combat and dialogues and plots, professionally done by the kings of RPG (Bioware). What I did was to basically connect the dots, from A-Z I just had to come up with A and Y/Z everything else from B-X was already available.

I am absolutely impressed of how beautiful and amazing the original code is. I know I'm a geek and I see the less conventional beauty of a Turing machine. I hope you can see it too…

The repository is now updated, so if you want to learn, go ahead and have fun . If you have questions, ask them on github

I may come back later if I have an update. For now my body is screaming for a break, the pain is..., well, hopefully you will never know…

 

Holy crap. Not even considering you having to overcome physical problems - your taking on a very difficult task! Consider me impressed, and best of luck to you!

 

well, after few days break, brain screaming 'keep me occupied' and body screaming 'give me a break', feeling between Scylla and Charybdis, I had to eventually come back to the project.

One thing I did, the character dialogues in an area are now parsed at loading time, and they are ready, and populate faster when the conversation is initiated. On the minus side, conversation initiated through triggers cannot be extrapolated from their parent XML, because they actually are called through scripting, so I don't have a solution for this yet.

I also implemented a basic main menu and loading screen as a proof of concept, pretty visuals are not my thing, so I guess I'll study shaders in the near future to see if I can make any sense out of them...

a snapshot of the main menu


a YouTube video of the main menu

the main menu scene is UI on the left side with transition toward transparency on the right side so that the 3-D mesh and lights and the wall can be seen seamlessly. And the particle systems attached to a bone, to get its position when its parent bone moves, so the flame sort of move slightly as the hand moves…

 

well, in the category of interesting ideas the brain randomly comes up with, mine decided that would be awesome to see if we can port full visual levels from the original game. So I proceeded to see if I can convert the original .lvl files that are using Bioware format into something that unity can use, which of course would be the ubiquitous XML

If you recall, in this proof of concept my starting point is the demo module, that happens to start with an area that uses ost101d.lvl as the visual layout, basically just a small hut in a middle of the swamp where you meet Flemeth for the first time. Converting from Bioware format (GFF) to XML was easy because there are tools already made by smart people in the community. My job was to figure out apples to apples what the information from the converted XML can be translated into something that unity can use, such as vertices, UV, normal, colors.

After couple of hours I had the conversion ready, and because I was feeling adventurous, my first attempt was a water mesh. ahem, what do I know about water?

Anyways, here is some sort of result


now for the life of me I can't figure out how to turn that solid green shader into an actual water shader, because in my tests once I applied the water shader, the water was basically everywhere in a full square. Anyways, I just asked the same question on the answers forum...

In case you're curious, below is a sample of how the XML water looks like, it's pretty straightforward which values from XML compare apples to apples with something that unity can digest

Code (csharp):

1.  
2. [INDENT]<?xml version="1.0" encoding="utf-8" standalone="yes"?>
3. <gff4 type="TRN" version="V3.1" platform="PC">
4.   <struct name="WAT ">
5.   <struct name="WATR" label="7900" alias="WaterInformation">
6.   <uint32 label="7901" alias="WaterVersion">1</uint32>
7.   <sint32 label="7902" alias="WaterID">6523</sint32>
8.   <struct_list label="7903" alias="WaterVertexList">
9.   <struct name="VERT" index="0">
10.   <vector3f label="7904" alias="WaterVertexPosition">
11.   <float>0.000000</float><float>0.000000</float><float>0.000000</float>
12.   </vector3f>
13.   <vector3f label="7905" alias="WaterVertexNormal">
14.   <float>0.000000</float><float>0.000000</float><float>1.000000</float>
15.   </vector3f>
16.   <vector3f label="7906" alias="WaterVertexUVW">
17.   <float>0.000000</float><float>1.000000</float><float>0.000000</float>
18.   </vector3f>
19.   <color4f label="7907" alias="WaterVertexColor">
20.   <float>0.640000</float><float>0.460000</float><float>0.410000</float><float>-2.411328</float>
21.   </color4f>
22.   </struct>
23.   </struct_list>
24.   <uint32_list label="7908" alias="WaterVertexIndexList">
25.   <uint32 index="0">0</uint32>
26.   <uint32 index="1">1</uint32>
27.   <uint32 index="2">2</uint32>
28.   <uint32 index="3">0</uint32>
29.   <uint32 index="4">2</uint32>
30. <uint32 index="4">3</uint32>
31.   </uint32_list>
32.   </struct>
33.   </struct>
34. </gff4>
35.  

[/INDENT]

 

update: with the terrain I got mixed results, I learned about heightmaps a little bit, but still issues with the water.

Meanwhile though, I did a little bit of 3DS Max scripting, a smart guy wrote a very good import/export script, that I borrowed and update it to handle batch processing and exporting, I had a glitch with the materials, because the original script was creating its own custom material compatible with the original Dragon Age, but unity was importing it as completely blank. so I shuffled things around the script so that a basic standard material is being created, and this time unity imported it somewhat better, in the sense that the material has now only to diffuse texture, for some reason normal/specular are completely ignored.

still, it's an improvement, because at least we now have bulk meshes import and basic material with diffuse only straight into unity, and the first demo area in this project is using 56 meshes, and automating the process is a definite lifesaver, or at least timesaver

I still don't understand why the material is being imported with only the diffuse texture, it would be nice if anyone/someone has a solution or nudge in the right direction...

still to do: parsing the level XML to get grouping, position and orientation of the 56 meshes

coming soon, eventually/hopefully

 

hmm, speaking of materials: I took a quick look under the hood at how serialized unity materials look like, and I found out for example that hexadecimal 2E ( well, a full double word 2E 00 00 00) translates into "Standard Shader", whereas hexadecimal 2D means "Standard ( Specular Setup)", and I did a quick test and turned some of the meshes materials from Standard into Standard Specular into unity just by changing that hexadecimal value, which of course simplifies and automates this process as well. Unfortunately doesn't solve the problem of why the material is being created with only a diffuse texture…
Well, I'll probably poke around some more into the serialized material with a hex editor, maybe something pops up eventually. Ideally, it's best to avoid manually updating gazillions of materials

On a passive-aggressive note, a few years back when I was working on my dancing videos in unreal engine, I don't recall having any problem with basic materials, diffuse/normal/specular textures being assigned properly, so I'm wondering if perhaps I'm missing some simple pattern to make the process seamless in unity as well, although as far as I can see the simplest pattern, which is predictable naming convention for textures, is already in place…

Anyways, back to work