Tool for converting Ultima Underworld and Shock 1 Levels into Unity.

[674048863884bCarrot]

Hmm, I seem to be having trouble extracting the zip file.  Anyone else having issues or just myself?

[6740488638990hank morgan]

I just downloaded myself to test and it works. I compressed and extracted using 7-Zip if that helps.

[6740488638ae2Carrot]

Oops, shoulda known better.  Yup, worked now.

Very cool Hank!  It was fun to run around and see.  I chose 1920x1080 for resolution (obviously much higher than original) but it was weird to see the GUI so fuzzy compared to the sharpness of the world textures and even items/goblins.  Have you thought about how you'll handle the water yet?

[6740488638c17hank morgan]

The image quality of the GUI is directly affected by the graphics quality you pick in the launcher. It looks a lot better when you choose fantastic quality.

My thinking with water that I don't do it as actual water but that I bring it back those sections as a separate section with a trigger mesh along the surface. So when you enter the trigger mesh I'll change the player movement/camera properties to simulate the original mushy movement in water.

[6740488638e05hank morgan]

So my previous process with Unity was I had to export to source vmf, convert with Crafty into an obj and then an obj into fbx via the autodesk converter. I've now updated my own crappy fbx exporter to the point where that process is no longer necessary and I can export them into fbx model format directly with the advantage that I can directly name tiles for manipulating them directly later on. This should work on all UW and  SS1 levels with textures mostly correct apart from some rotated floor textures.

Some in editor screen shots.
Image: http://i.imgur.com/w1WcEmZ.jpg
Image: http://i.imgur.com/RI9ZuUW.jpg
Image: http://i.imgur.com/CVAeUTy.jpg
(those faint lines are because I had clicked on the model)

[6740488638faehank morgan]

I've gotten a first pass done of a UW style inventory system done.
-It can pick-up and drop objects in the main window.
-Update the mouse cursor to show what is being picked up
-Swap with objects already occupying the slot.
-Objects can be dragged out of containers up into their parent or around to other slots.
-Supports nested containers.
-Objects dragged onto containers will be added to that container.
-Containers can't be dragged into themselves or to their child containers.

At the moment it's main limitations are
The paper doll (helmet, armour, leggings and boots) does not update because I've yet to reference back to the correct artwork for the bodies.
Each container object can carry up to 40 object slots but at the moment I only show the first 8 objects in the list.
Dropped objects will only appear at the player position
Every slot accepts every type of item So you can wear a loaf of bread on your head if you wanted to.
Image: http://i.imgur.com/UHktiHD.jpg

[67404886393c0Kolya]

you can wear a loaf of bread on your head if you wanted to.

How is that a limitation? Useful and nutritious I say!

[674048863954bicemann]

Plus does wonders for the hair.

And awesome work on the containers. Not even SS2 had that level of functionality with those.

[6740488639789hank morgan]

Since my last update I've ran some successful tests using a plug-in for managing level persistence but the main advance since then is that I think I have a solution for the animation problem.  Thanks to the documentation in uw-formats.txt from the Abysmal and Underworld Adventures projects I was able to modify my existing critter extraction code to produce an editor script script that generates animation assets for each possible critter type. The script takes about 10-15 minutes to run on my pc but believe me that is way way way more preferable to hand matching 3000+ animation frames(in UW1 alone). The attached image shows a number of creatures in various animation states including walking, idling, dying and attacking

Image: http://i.imgur.com/LfFxU4E.jpg

I do have one big problem to solve. As it stands I have to bundle assets(such as the maps models) into the build and if I ever get to the point of making proper releases this would leave me uncomfortable as it strays over the line with regards to copyrights etc. Obviously I would want to require to player to have a copy of the originals in order to play my version. So I just want to present my solution to see what people think.

The way I generate content in the editor is to use my existing tools to produce a script that defines and creates all the various game objects I spawn. My one design rule with those scripts is that they have to run in both the editor, at runtime in the player and in an final exe build.

My thinking therefore to bundle a special version of my tool that produces a text file in a suitable format from the original files that can then be loaded at runtime and when a level is loaded it will only then populate the level with objects. Without that data all you have is a empty map from which you cannot leave. Does that make sense?

[674048863992aKolya]

What would keep anyone from packing and distributing that key file together with your game? And are you absolutely sure this file would be generated the same way with every game out there? Also, is hank morgan your real name?

[6740488639a68icemann]

Anything copyright direction, best not having your real name around.

Though if it's for abandonware related stuff, then the risks are somewhat lower.

And requiring the user to use their cd to grab assets via an installer / setup tool is usually what works best copyright issues wise. Many projects have gone down that route.

[6740488639d7fhank morgan]

Hank Morgan is not my real name.

Anything copyright direction, best not having your real name around.

Though if it's for abandonware related stuff, then the risks are somewhat lower.

And requiring the user to use their cd to grab assets via an installer / setup tool is usually what works best copyright issues wise. Many projects have gone down that route.

This is what I ideally want to do. Loading the objects at runtime should just be a part of that process. I think I'll just not release any more prototypes until I've gotten a better solution to the problem.
On my end I can also try and keep good documentation of the build process and share out the non-copyrighted original work portions and tools so that even if I never release anything myself, interested parties can go ahead and pick up the tools and homebrew their own.

Thanks for your opinions.

[6740488639e91hank morgan]

There does however seem to be tools for editing asset files. So maybe my answer lies with one of those.

[674048863a030hank morgan]

So after a little bit of research I came across a script for loading .TGA files which is what I usually extract graphic images into from my tool. The attached image shows both a wall tile and a sprite rendered with a tga loaded from an arbitrary file on my computer. That at least solves some of the problem of asset distribution for me. I'll press on with development with resources pre-loaded in the editor but at least now I know if it comes to it I could replace a whole load of  graphics assets with blank place-holders and then just extract and load them at runtime. I still would need similar solutions for the model mesh, path finding mesh and I reckon I'd have to re jig my animation system but at least with this bit of knowledge I can kick that can down the road to when I know more about what I'm doing.

Image: http://i.imgur.com/ErFhwgW.jpg

[674048863a104icemann]

Looks great

[674048863a46ahank morgan]

I was hoping to do a proper status update with a short video this week but a few unexpected real world things came up. I expect slow progress over the next two months due to time constraints but work will still trundle on.  The project commit log is at https://github.com/hankmorgan/UnderworldExporter/commits/master if anyone is interested in my progress.

The quick version
-I've laid down the basics of a magic system. I can now pick up runes, store them in the rune bag. Select runes from the rune bag and build up the magic words comprising of a spell in the "spell shelf". I can then click on the shelf and for most spells it will just tell me in debug what I've cast. But I also did a quick implementation of the basic magic missile spell  which I can ready and aim. The picture shows me killing poor Bragit with a spell. The method of launching a projectile will be the much same for implementing guns whenever I get around to doing them.

-Simple melee attack (no swing graphics implemented yet). I can now go into attack mode. Hold down the mouse to build up an attack charge and then apply damage to the object at the mouse cursor when I release the button. Enemies can also be set to execute an attack but due to laziness on my part their attacks are currently fired from their feet so they won't hit the player unless they are above the player.

-Objects can now be thrown in the view.

-I've done a small bit of UI work for switching between inventory, stats screen and the run bag. I can also switch to the automap screen. There is no map yet but I have done a successful test in tracking which tiles the player will step on so I hope that an automap system will be possible in the future.

Image: http://i.imgur.com/1oX4WXn.jpg

[674048863a617Mako]

I have a very silly question: Is http://doomwiki.org/wiki/UDMF support doable?

[674048863a742Join2]

Fine job, Hank.

[674048863aa93hank morgan]

I have a very silly question: Is UDMF support doable?

It is to an extent. I glanced at the format a few months back when someone else asked a similar question. I think the big issue is how you would handle sloped floors and ceilings.

Essentially in Shock & UW there are only a small number of tile types. A solid and and an open tile which are pretty much identical except for height. Then you have your sloped floors and your angled walls which are just an open tile with the angled portion connecting opposite corners. Shock adds an extra couple of wrinkles with ridged and valley tiles but you can just do them as sloped tiles merged together. All you need to get a full level is know how to implement about three basic shapes.

All of this is well document in the ss-specs.txt and uw-formats.txt from the various earlier projects. I have a great deal of gratitude to the trailblazing of those projects.

[674048863ae51Mako]

I think the big issue is how you would handle sloped floors and ceilings.

Depending on the source port in question (vanilla support is obviously not happening if the maps are written in UDMF format) there are quite a few ways to put sloped floors/ceilings in one sector at a time. For example, http://zdoom.org/wiki/Slope. The main caveat, I guess, is that one tile must be broken up into several sectors in order to translate certain SS slope types like ridges and valleys. That could make things more complicated but I can't think of any specific problem that couldn't be automated away.

[674048863af81hank morgan]

Just popping by to say I'm still alive. Haven't done much since I last posted apart from working on doors but still plugging away from time to time. The .fbx model exporter is now at least as functional as my original dark mod one.

I'm going to try and document my process of getting a level up and running in Unity before the end of the year. I'll let you know when I get that done so as to give any interested hobbyists a chance to see what they can do.

[674048863b6dcBenNM]

I'm going to try and document my process of getting a level up and running in Unity before the end of the year. I'll let you know when I get that done so as to give any interested hobbyists a chance to see what they can do.

Yes, please!  I find this all very interesting, and it's good to see someone with 'old-school' skills approaching a project like this and making significant progress.  I've dabbled in game/interface creation with Visual Basic 4.0 (a while ago) and more recently helped a couple people with Elder Scrolls (Morrowind & Oblivion) script-based game expansion (aka the Craftybits mod).
  As well as Fallout 3 and Fallout New Vegas.  Anyway...

I've been keen to create random-ish gaming systems on graph paper using dice and even managed a graphical island/continent generator using set angles with random distances from varying 'center' points.  That was maybe 20 years ago?  Since then, much more graphically interesting and capable engines have become available.  Always the 'problem' of abstracting data and organizing it for storage & retrieval - and deciding how 'large' levels should be and how much info to store in active memory at any given time.

I certainly admire what you're doing and how far you've come with it.  Currently (recently) I've been thinking about a realistically animated top-down interface somewhat like Teleglitch, the videos of which are ...well... amazing and quite intense / gritty.  Alternately, I've been messing with a relatively simple paper-and-pencil (and all 6-sided dice) system that would translate well into digital format, which players around the world could access as teams - much like digital gaming tables, et cetera. (and, yes, I'm somewhat influenced by the old Shadowrun books/system)

I would offer/suggest/request that when you get around to adding guns, the recoil be somewhat like System Shock 2.  Having fired a fair few real guns, I can appreciate how the angle of view climbs with each recoil -- as in, you end up looking upward a bit more after each shot and have to use the mouse to bring the point of aim back down. (this effect obviously compounding with auto-firing weapons)  The real reason for barrel climb is... the barrel is above the anchor point (hand/shoulder).  This is partly on purpose (to direct some of the kick upward) - and also a practical design aspect. ...I won't start a discussion here about different types of ammunition, bullet weights, and internal ballistics / recoil cycles and how that affects point of impact -vs- point of aim. (barrel whip and harmonic stabilizers also affecting when/where high velocity rifle bullets leave the barrel, different types of compensators, bolt & feed mechanisms, heat discipation, etc) 

Anyway, I/we have found that pure realism is difficult and tedious to achieve within a game.  Often, players do not perceive or appreciate true physics.  Instead, I/we found that practical shortcuts that approximate real-feeling game experiences are the way to go.  Also, immersive & memorable games often have at least a few (though not necessarily 'many') hook-like aspects - atmosphere, interface, humor, gameplay, control-feel / handling, etc.

There is a curious coined concept of "the uncanny valley" - in which 'cartoonish' characters are easier to relate to than 'near miss' ... 'almost realisitic' characters.  Too near real human faces and movements... and players are more likely to notice and be put off by the differences.  That's where the climbing slope of relational resonance dips and fails - the uncanny valley.  Another example is a manequin that draws your attention back to it with a feeling of unease (and not in a good way).  Climbing up out of that valley takes a lot of computing power and speed to present a level of realism that viewers do not question and do begin to relate to again.

...A good friend of mine actually prefers watching old tube-style television.  He's also a 1980s style toy designer with ...plans.  Many of the business/distribution ideas are his, so I won't repeat them publicly.  One thing he has mentioned is that we currently have more technology than we need (or want).  Things are too complex and often so 'finished' that it leaves little room for people to fill in the gaps via imagination.  Something a little simpler and more 'retro' seems to be in order, for what we're planning at least.

So.  I can certainly appreciate what I'm seeing here so far.  Please continue to post your progress, and hopefully a video of some sort before overly long.  I'd also be interested in the details of your gaming system... perhaps in an easily accessible web page format or test file.  Don't worry about me copying it; I have my own ideas.  =)

- Ben (Shaeffer) ... recently from New Mexico, USA

[674048863ba2chank morgan]

As promised. Basic instructions on how to export a  level from the tool
Covers the basic folder layout.
How to extract and import textures & sprites.
How to extract and import the FBX map file.
How objects are generated in an editor script.
How to create a player.
How the UW HUD is set up
You'll need to download the zip file from the project page for the program code & exe, the instructions. texture & object mapping configs (these are important as they need to match the art) and Unity script examples. The gamepaths.txt file will need to be updated accordingly.

https://github.com/hankmorgan/UnderworldExporter

Hopefully enough for someone to get started if they wanted to.

It probably won't all work like it does at my end but I'd imagine anyone interested will jump straight to attempting to bring in an SS1 level and start experimenting from there. If you want to get started on an SS1 level you'll have to match the sprite artwork up in the config files. I've only done a small bit of research on this topic based on the what is documented in SSspecs.txt  Basically each sprite has at least 3 different frames (low/med/high res) plus a number of extra frames for animations. Although each object 'block' is in order the individual frames may not be. So I think ultimately I'll have to bit the bullet and match things up by hand.

Use at own risk etc etc.

[674048863bb64icemann]

Matching up by hand generally works best. Takes ages, but it provides the best results. Just dedicate a day for a couple of AI's and go from there.

That's what I did on my last project. That way you get to fully test them out, make sure everything's working up to spec before moving onto the next one etc.