Stargem on 15/2/2013 at 08:40
With the release of the New Dark engine, it pretty much means that someone out there has the source code for System Shock 2 - thus creating a complete remake of the Ultima Underworld games is possible. The planets can potentially align.
I kind of hope that happens, as playing Ultima Underworld is a bit obnoxious when it comes to the interface, inventory management, and trading with NPCs.
Al_B on 15/2/2013 at 11:23
Not sure I understand what you mean. The System shock 2 engine is completely different to the Underworld engine.
Stargem on 15/2/2013 at 22:14
System Shock 2 uses the Dark Engine, and resembles Ultima Underworld when you look beyond the sci-fi trappings. For example, there is a number of abilities accessible through psionics that allow telekinesis, healing, creating barriers, teleportation, and so forth. We also got an inventory system, a paper doll for worn equipment, skills, stat terminals, weapon degradation, swimming, ect. Through hard work and a lot of time, it would be possible to reflavor and rework these elements to closely resemble Ultima Underworld - with one exception: Conversation. There is no such system for the Dark Engine, but with the source code it could be possible to add such a system.
The underlying foundation for a Ultima Underworld remake is there in my opinion. To be sure however, it would take a considerable amount of work and time to get something like this off the ground, for any engine.
icemann on 20/3/2013 at 23:04
That would take a hell of alot of work to do. If it were even possible. Getting the interface up and running alone would take a fair while. And then you have enemy AI (which for UW was extremelly basic from memory) + the magic system.
ZylonBane on 23/3/2013 at 15:40
The other big thing that seems to kill a lot of remake projects, other than the coding, is the enormous task of creating/texturing/rigging new AI models. That's a rare skill in the amateur modding community, and anything less than an excellent job of it can single-handedly ruin the perception of a mod.
Jason Moyer on 8/4/2013 at 09:18
Why not use the Arx engine? It's open source and the game it was designed for is basically Underworld 3.
Running_Wild on 22/8/2013 at 18:19
Two good engines that would take away the legwork of the graphical side of things would be (
http://unity3d.com/unity/download/) Unity or (
http://www.unrealengine.com/en/udk/) Unreal.
Note that no current engine really supports the tile-based format that Underworld uses and UW has it's own system with stats ranging 0-30. All these things would need to be constructed from scratch. Then the physics as someones else mentioned. Then... well, the rest of it. There's no short path. A game is just a tremendous amount of work. There's no way around this, no matter what engine is used, unless they suddenly release the source code out of nowhere which I'm not holding my breath for.
Original UW Editor :
Inline Image:
http://web.archive.org/web/20041129040304/http://www.owo.com/archive/ftp/graphics/uwdesign.giftwisty on 23/8/2013 at 19:18
That's very cool. I've never seen a screenshot of the editor before. It looks a lot like dromed but much more colourful.
Al_B on 23/8/2013 at 22:40
Not sure where Running_Wild actually got the screenshot from (but would be interested to know) but I do know it was included in the old Game Bytes interview with Doug Church and Paul Neurath back in 1992. The relevant part of the conversation about the editor was:
Quote:
GB: What type of design tools do you use to create the dungeons,
characters, generally the whole game? Did you create an 'editor' of sorts
to 'layout the game'?
Doug: Absolutely. We have an editor we use to layout the dungeons and
the objects. In fact, see the accompanying screen shot. (Press F-10 or
left mouse button). Until March of 1991 we only had an editor. The game
is written so that the editor, the playtest game, and the shipping
executable are all the same code. Various compile time flags are turned
on and off to set what gets put in (enabling and disabling various
subsystems and subeditors, allowing various cheats and cheat menus, and so
on).
The editor allows the designers to terraform and texture a level, and then
place objects in the map as they want. The object browser allows the
designer to bring up data on the current object such as quality, status,
and so on, and edit any special flags for that type of object (what spells
are on it, data on traps and timing, directions doors open, and so on).
From the editor, a single key stroke or menu choice allows you to enter
"game mode" in which you can just play the game (although you can disable
creatures, set quest flags, teleport around, and so on).
So the designer typically works in the editor to set up a particular room
or scene or trap or puzzle or conversation, saves the work, pops over to
the game, tests it, then goes back into the editor and reloads and
changes it, all within the editor. The only design task not built into
the editor is the conversation compiler, which is a standalone piece of
code.
For conversations, one writes a source file and compiles it, then goes
into an editor and creates the appropriate character, and then can go
into game mode and talk to said creature. Overall, I think the editor is
the coolest piece of software we have written, but mostly just because it
is the most complex.
Very cool indeed, particularly given the era in which it was written.
Shadowcat on 24/8/2013 at 01:11
Very cool. I read the Game Bytes interviews, but I think I only had the text. I never ran the software versions of the issues, so I'm not sure I've ever seen that editor image before.
As for remakes, I've long held that the only practical way of creating a remake of these games is to actually be running the original code.
I simply don't believe that a small number of people are going to accurately recreate all of the game logic from scratch in their spare time, without any source code.
OTOH, something which executed the original code and functioned as a layer between that and the modern code (to translate user input, audio, and rendering) might have a hope of resulting in a complete game. That would still be <em>extremely</em> difficult and complex, but I think it reduces the scope of the original code that needs to be understood for a full recreation of the game. People would effectively still be playing the original game.
It also puts the focus firmly on "making the game work". If that was actually achieved, well <em>then</em> you could start to think about making it prettier. (I think that the projects which start out with fancy graphics and no concept of how to implement the <em>game</em> are always going to be doomed.)
Not that I believe that anyone is going to do this, mind; I'm just not convinced that other approaches are worth pursuing in the long run (although presumably some of the existing attempts could be used to provide the modern rendering solution).
