26 réponses à ce sujet

[5ai]

Hi there!

My name is 5ai, and I've been working around the clock lately to compile a complete overhaul to the original Neverwinter Nights game, both as a school project, and as a personal challenge. Ideally, I will be changing every last detail of the game, down to the GUI to it's ruleset. The idea is to create a sort of open-source game, that'll allow other people full access to mod the Aurora Engine however they'd like. (This being an unofficial MOD to NWN 1! Not a standalone)

However, in my progress, I've seen some very interesting traits within the Bioware games. Between Aurora, Electron, and Odyssey, I can't help but wonder Just what changed between the three? 

I've been a long-standing fan of the Bioware franchise (Well, the legacy games), so when I look at the individual files, and scripting, I'm noticing many similarities between them that makes me wonder if you could truly run one's game files within another, following override files, and filetype conversions. 

So far, the only REAL change I've seen is adding new features, changing model types, general GUI/Scripting/Ruleset changes, and different ways that the Modules files were read. 

Here's my question- What would be the biggest limiting factor stopping us from running, say, KOTOR within the Aurora Engine, given that we override certain files? 

Just a bit curious, wondering if anyone had any insight into this info.

[kamal_]

http://forum.bioware...-remake-of-nvn/

I'd guess that Dr.McCoy feller knows more about the engine details than pretty much anyone who posts here (excepting skywing, who doesnt post much). His Xoreos project should eventually run nwn1/2, witcher 1/Jade Empire etc. Also his project needs help from proper coders, so you could help him, get your school credit, and work on a real world (not for school) project.

[rjshae]

> However, in my progress, I've seen some very interesting traits within the Bioware games. Between Aurora, Electron, and Odyssey, I can't help but wonder Just what changed between the three?

 

I don't know about Odyssey, but the biggest change between the Aurora (NWN) and Electron (NWN2) toolets was the addition of external areas that could be sculpted and textured. Aurora is entirely based on tiles, which makes it easier to build areas but also limits what you can build. After using both I find that Electron is more flexible and powerful to use overall, which is what you'd expect for a subsequent engine.

[DrMcCoy]

Yes, there are quite a lot of similarities between the games, which is what I base by xoreos project on, after all.

However, you can't just plonk files from one game into another and expect it to work. They are not that similar. The formats have changed, the expectations the engine has on these files have changed, and the structure, how they are held together, has changed.

To give a quick run-down of your KotOR in NWN example:

• The GUI system is entirely different. NWN uses model as widget primitives, KotOR uses textured quads
• In both games, the GUI is also mostly hardcoded. The game knows there's a button "New Game", and what to do when it's clicked, only the looks are taken from the data files. I.e. you can't create new functionality or differently behaving GUIs
• The module structure is different. An NWN game consists of one to a few mod files, each with several areas in them. KotOR consists of a slew of mod files, each with one single area. This has a lot of repercussions on how saving/loading works, how objects behave when they transfer across area boundaries, etc
• The area structure is different. An NWN area is tile-based, with all tiles of the same size. KotOR is room-based: arbitrarily sized rooms, each one model. The assumptions the game makes about each makes them not directly interchangable
• The script engine functions are wildly different. These are the ~800 function definitions you find in each nwscript.nss file; they are functions called by the scripts, but implemented by the game's executable. Yes, there are some commonalities, like math functions, and string manipulators, but a lot of things are very game-specific
• The models are very differently structured. In NWN, each model is a collection of small nodes, with some geometry attached. For example, the hand is a node, the lower arm, the upper arm, the shoulder, etc. Animation is done by moving and rotating the node hierachy, while leaving the geometry untouched (except for jiggly meshes, like hair and cloth, that deform a bit when moved). In KotOR, you have a huge geometry blob for the whole body, and the vertices inside move according to the node structure. This is a very different approach to animation
• The rulesets, while quite data-driven, is still hardcoded in places. The game just needs to know that, for example, a cleave or a lightsaber throw exists and what it's supposed to do.
• The renderer is slightly different. You see, for example, that KotOR can attach simple ARB shaders to objects, to get effects like the shimmering on force fields. Environment mapping is also blended in differently

This list is of course not exhaustive. I probably forgot a lot. I also haven't snooped that deeply into the actual gameplay yet. Also note that there's changed functionality in the script interpreter in later games that can't be easily replicated. For example, KotOR2 and NWN2 have a feature where you can run several scripts in a dialogue and have the results boolean-and or boolean-or together to get the final result; NWN2 added parameters to the main()/StartingConditional() function; Dragon Age: Origins and Dragon Age II each add two new bytecode opcodes (for arrays and for references, respectively).

So yes, you could get an approximation of KotOR in NWN, but you need to:

• Rewrite the GUI. Or rather, reskin the NWN GUI to mimic KotOR
• Recreate all models, including textures where they use features not in NWN
• Recreate the object (placeables, creatures, NPC, ...) templates, or find a way to automatically convert them somehow
• Rebuild the areas
• Merge all KotOR mods into one mod with several areas (and mind that object transferal now works while it shouldn't!)
• The dialog files can probably be automatically converted
• But you need to rewrite all the scripts
• And you need to mimic a lot of the changed rules and concepts. They don't transfer 1:1

Me, I don't think that's a worthwile thing to spend time on. But what do I know, I work on xoreos...

[kevL]

heh. Good luck, McCoy. if & when it gets to a higher level (sic) expect more pull requests.

The OpenXcom.org project took about five years to reach playable maturity --

[DrMcCoy]

The OpenXcom.org project took about five years

commit b558f683f86a4e56a1e5336e4c026ec3517fa8fb (tag: v0.0.1, tag: desc/0.0.1)
Author: Sven Hesse <drmccoy@users.sourceforge.net>
Date: 2010-03-26 03:52:20 +0100

Initial empty frame

[kevL]

yeh but look at the difference, in both complexity and scope

so, just get the low-level stuff down and we'll put the games themselves together

[DrMcCoy]

Hmm, what's "the low-level stuff" for you? This is the current state of Neverwinter Nights in xoreos: https://www.youtube....h?v=_EZRvDIB7wI.

The next step would be walkmeshes, and walking creatures and pathfinding. Then rigging up the camera over the PC. Then triggers.

Granted, the later games are not quite as far. Dialogues are missing. GUIs mostly too. But they do all show in-game areas and run scripts. Development of "low-level" things and "high-level" things go hand-in-hand, mostly. The best time to jump in is always now!

What's painfully obvious, though, is that the renderer is...not good. That's a naive fixed-function OpenGL 1.2-era renderer (though it does use VBO/IBO for models) I hacked together, because I know jack about OpenGL [1]. That needs to be rewritten with a more modern shader renderer [2]. We do have someone who has started on this, but it's unfortunately stalled at the moment, for lack of free time. Might be great if another person could step up join, so that this task could be continued together.

We're also not short on other tasks. Some are standalone-ish, some would build upon things already implemented, some would be the base for further progress. Some tasks are of the low-level format spelunking variety, some are higher-level-ish concerns, some are more about software design, some about localization/usability, some are detours that would help debugging and/or the modding scenes.

As far as I see it, there will never be a point where I can say "Oh, the low-level things are finished, now I'll do only high-level head-in-the-cloud tasks". That's not how I operate. I grab one thing, build it from the ground up, then apply that to the existing code-base, then apply that to all the games uniformly. At least in general, there's some exceptions and stuff, but you get the picture.

Or, to cut a long rambly story short: join my cause, we have cake!

[1] I do have a WIP branch that evaluates NWN lighting: https://drmccoy.de/x...0809T223407.png. The rendering code would be obsolete with a proper shader-based renderer, though.
[2] OpenGL 3.2 with OpenGL 2.1 fallbacks for portability/compatibility, is what I envision

[kevL]

I'm most comfortable with 'head in the clouds' polish stuff. I notice a missing sound-call, i fix it. Pathfinding wants to go left but i think it should go right, I can probably fix it. I wouldn't have a clue where to start with implementing openGL or designing shaders.

My motivation stems from this: There are bugs and limitations in the NwN2 engine that stick in my craw. Like ActionCastSpell... bCheat is hardcoded at casterLevel 10. AoE's don't track all the data they should. Auto-fail save on 1 is bugged .... Combat mechanics are well nigh impervious to external influence, etc.

but decoding file formats and creating walkmesh classes aren't my forte.

--
If I fork & build the codebase, is NwN2 capable of loading?

[DrMcCoy]

If I fork & build the codebase, is NwN2 capable of loading?

Yes. There's no main menu [1], but you will be thrown into the first area of the OC prologue/tutorial, and starting scripts will run [2]. You can click on doors and containers to open them [3], and you can click on a door with an opened state to go through it. I.e. you can transfer to the outdoor area of the OC tutorial by clicking twice on the door.

By pulling down a debug console with Ctrl+D, you can move to other areas in that module, or load another module.

We have some rudimentary help on how to compile xoreos on our Wiki here: https://wiki.xoreos....ompiling_xoreos. If you're running Windows, setting up your environment to compile xoreos is a bit cumbersome, though, because of the library dependencies you need to hunt down manually on Windows. It might be useful if someone could create some kind of bundle with all the dependencies, precompiled (ideally for both MinGW and MSVC) [4][5]. I've seen Arx Libertatis do this; no idea how transferable that is. Me, I'm a GNU/Linux person, so I wouldn't know.

[1] The NWN2 GUI needs an XML parser that doesn't choke on NWN2's broken, horrible, just plain bad XML files. Or something that can repair them so we can throw them into libxml2
[2] But not do anything visible beside print stuff to stderr
[3] They won't animate, though, so don't see that they've been opened
[4] No idea how interoperable different MSVC versions are, though
[5] And keep it in sync

[kevL]

[1] The NWN2 GUI needs an XML parser that doesn't choke on NWN2's broken, horrible, just plain bad XML files. Or something that can repair them so we can throw them into libxml2

i've put all the xml through Charlie's XML Conformer and they've never failed.


other than that, certainly sounds interesting and I'll give it a whirl (windows). Don't expect anything soon tho :)

[DrMcCoy]

Yes, something like Charlie's XML Conformer is what xoreos needs. It would need to be integrated into xoreos, so that it can transform the XML files on-the-fly in memory while loading them.

Unfortunately, we can't use the source code of Charlie's XML Conformer: he didn't attach a valid free software / open source license. Or any at all, really. "Furthermore you are free to use the source code provided in your own programs" is too unspecific.

I.e. someone would need to write the cleanup from scratch, or find a way to get ahold of Charlie and ask him to put an explict license (that's compatible with the GPLv3) on his code. Also, his code is C#, while xoreos is C++ (with its own UTF-8 string class), so it might not transfer this easily in either case.

[kevL]

her

[DrMcCoy]

Ah, crap, yeah, sorry, assumed gender and pronouns from the first name alone. I need to stop doing that.

[kevL]

i'm sure she's used to it ... (i think she's a she, i am really darn sure but..)

[Tchos]

The docs for something of hers seemed pretty clear on it.

[Mistraven]

Good luck with the Xoreos project, it looks very cool so far! Personally I'm just a beginner at programming, have mostly done web-development with php, xml and javascript, so I probably won't be able to help you guys, but keep it up anyway! I'm looking forward to see the development!

[rjshae]

Yes, my days of fervent coding are behind me now, or I'd be very interested in this project. It does look promising and I hope you get more help to make it happen.

 

P.S. For publicity purposes, you might consider trying to post a message about your efforts to ModDB, RPGWatch, and SlashDot. That may help draw in some other interested parties.

[kevL]

It's alive!

[kamal_]

It's alive!

 

What are we looking at? NWN2 native stuff in Xoreos?

[rjshae]

What are we looking at? NWN2 native stuff in Xoreos?

 

Judging by the lack of shadows, tinting, and normal map, I'd say that's probably so. It's looking good otherwise.

[kevL]

xoreos v0.0.3 drawing NwN2 OC tutorial area (Daeghun's house, interior)

compile time: ~45min. on a Pentium D925


it's, yeh, eye-opening

[DrMcCoy]

compile time: ~45min. on a Pentium D925

That's pretty extreme. On my Athlon 64 X2 6000+, which is also a 3GHz dual-core CPU from around 2006, a full recompile only takes 9 minutes (on GNU/Linux, with gcc 5.2.1). Have you tried switching on compiling with multiple jobs in your IDE? I generally compile with make -j3.

[kevL]

no i haven't played around with stuff like that yet. Pre-compiled headers, when i get there, should chop the time down drastically, i imagine

[kevL]

"make -j2" cut the time in half, Thx

but "make -j" (unlimited) riled up my ptsd. not pretty.