Dragon Age 1/2 engine porting to Unity

[room101]

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

[Kurt-Dekker]

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!

[room101]

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

[room101]

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

[room101]

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…

[CWolf]

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!

[room101]

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

[Kurt-Dekker]

@room101

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!

[room101]

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

[Acissathar]

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

[CWolf]

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.

[room101]

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…

[Kurt-Dekker]

@room101

while contemplating the existentialist dilemma of a conversation interface

Why… I was doing this JUST the other day!

[room101]

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

[room101]

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/YetRPG/blob/master/Assets/packages/core/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

[CWolf]

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.

[room101]

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…

[room101]

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

[room101]

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.

[room101]

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…