Future

[Legacy_Rolo Kipp]

               

<ducking and dodging...>

 

@rolo kipp <snip> however right now I don't immediately agree with this point: "support legacy content for NwN and NwN2, including assets, scripts and entire mods". I think would be easier to provide tools to convert from one format to another. Also we avoid patent issues with this decision - I'm not a lawyer, but I don't think we can use that formats without owning the game. Also, supporting mobile would be **great**, but maybe is a step larger than we can take at a start? Since it mainly takes only the graphical part, I think you should know better.

 

also, congratulations! :-)

 Last first: Thank you :-)

 

The actual implementation will use importers/exporters. I also plan to support other formats (such as nif and fbx). The idea is to tap into the incredibly creative *community provided* assets that are *not* owned by corporations. Specifically, we can *not* release licensed content without written (and at this point, impossible to get) permission. This means we *can* provide an engine or tools that are capable of *using* NwN, NwN2, Unreal, Skyrim, Fallout, Silent Service... et al. assets, but we can not provide those assets (including the entire D&D 3.0 or 3.5 ruleset!). Some one wanting to play NwN or NwN2 on the new builds (either Xoreos or AT, or anything else that happens) will be *required* to own the game. The formats themselves are available for community use, as each of the above mentioned games not only supports, but actively encourages modding.

 

In regards to mobile clients, tablets and even phones have graphics capability approaching or passing those of computers in 2000. There will need to be platform awareness adjusting not only resolution and LoD, but also processor threading and data scaling, but I fervently believe any hardware capable of running Android 4+ should be able to provide a client for MP RPG.

(Edit: Also, jME is cross-platform with support for Android built in, so, other than the platform awareness, anything I build will work on the three main OS (via JRE) with little to no modification).

 

Not, perhaps a server, but definitely a client.

 

<...weaving and ouch!>

               
               

               
            

[Legacy_RedConfusion]

               

Although we can use but not distribute the neverwinter nights content, I'm afraid in ending up with the requirement of having to own the game to be able to play at all. Creating a game client and the toolset from scratch is 95% of the work on NWN. If we could go this extra 5% and avoid the necessity of players buying nwn to be able to play, I think would be great. For that we can use the community models, and possibly ask for content creators for other models. This enters as the "breaking free from bioware" line of thinking.

 

It seems that I'll take a few more days on the travel, but I should have something online until the end of the week.

               
               

               
            

[Legacy_DrMcCoy]

               

Creating a game client and the toolset from scratch is 95% of the work on NWN.

 

I really think you underestimate (and undervalue) the amount of work it takes to create models, textures, images, sounds, music, designs, ...

 

For that we can use the community models, and possibly ask for content creators for other models.

 

If you just take existing community models and slap them together, you're ending up with an ugly mish-mash mess of different styles. There's a myriad of shitty games on Steam that try exactly that, and without fail, the end result is bad. No artistic cohesion, no rhyme or reason, no nothing.

               
               

               
            

[Legacy_RedConfusion]

               

@DrMcCoy I see your point, thanks!

               
               

               
            

[Legacy_NWN_baba yaga]

               

One little thing about lighting... the way they did it with GTA san andreas was ok to me. They used shadowmaps for the environment and if i´m not mistaken just "diffuse" light for the character models. It´s a very good way when you have broken apart models like in nwn. You dont have these ugly smoothing group bugs where the joints meet and yet an environment that is perfectly lit. Models take the diffuse light setting from the scene of course '>. Well.... i´m doing stuff with AGS anyway from now on... hehe. Anyway, if you guys have something that actually works and is useable you can count me in on some environment stuff. But only if i can just build it in 3dsmax and lit it there or use the shadowmaps at least '>

IT´s just frustrating to have so many good textures done + all the objects and you cant use them because they look ugly without any good lighting. The more details you add the worse it looks in nwn to me now a days and i´m realy not spoiled. I dont like all the uber graphic stuff but lights and shadows are a must have. 

               
               

               
            

[Legacy_RedConfusion]

               

Here is the project link for the d20 backend: https://github.com/fotanus/libd20

it stills a very young project because my C++ is 10-years-rusty. Also I never had to write C++ code to be cross platform, so I spent some time learning cmake.

 

Contributions are welcome!

               
               

               
            

[Legacy_Guest_TrillClinton_*]

               

Here is the project link for the d20 backend: https://github.com/fotanus/libd20

it stills a very young project because my C++ is 10-years-rusty. Also I never had to write C++ code to be cross platform, so I spent some time learning cmake.

 

Contributions are welcome!

I would make some of these abstract classes or even interfaces while possible. That way I am programming to an interface rather than a concrete class. It just makes it easier to maintain.


I like the code tho
               
               

               
            

[Legacy_DrMcCoy]

               Hmm, here's a few things coming to my mind reading your code. Some of them are personal preference, some nitpicky, so feel free to ignore them:

• Please add a proper license to the project. See the choosealicense.com for some options, then stick a LICENSE or COPYING text file into the root of the project. You should probably also specificy the license name in the README and add some comment header with the possibly abridged terms to each source file
• Personally, I am no fan of CMake. It's always so fiddly when you want to build something out of the ordinary, like with a cross-compiler. I like the autotools, but I'm probably in the minority there
• I'd use standard include guards instead of the non-standard #pragma once
• You're mixing indenting styles (sometimes, you indent with spaces, sometimes with tabs). Not good. Personally, I'm one of those people who really like the "tabs for indenting, spaces for alignment" maxim
• Depending on how you plan to allocate and deallocate the Race and Class classes, they probably need a virtual destructor
• Not sure a virtual get_name() is the best idea. I'd stick the name into the base class and fill it in the child classes' constructors
• You're missing spaces between the #include and the < a few times
• "this->name = name"? That's why I like to prefix member variables with a _, but yeah, personal preference. I also prefer initialization lists to the these kinds of assignments
• You're using this->name ins getters too? Okay... Not what I'd do
• "using namespace" is often a bad idea. Sure, it's a namespace you wrote yourself and it's just for a test, but you're still potentially polluting your namespace with things you're not using

               
               

               
            

[Legacy_RedConfusion]

               

Disclaimer: I'm not a C++ expert. Now, lets try to find the best thing to do:

 

@TuringComplete: The problem in having a pure virtual class (that is the abstract from c++) is that I can't declare the hashmap for class->leves like this:

std::unordered_map<Class*, int, ClassHasher> classes;

Is that right? If you still can, can you please explain me? Or better yet, send me a patch request showing how?

 

DrMcCoy:

 

• License: Will be MIT or BSD, or anything very permissive.


• Build too: I used autotools in the past, but the thing is that it don't run on windows without cygwin. cmake can even use visual studio compiler. We want compatibility with many OSs, so I tought it was the way to go. Not to late to change that!


• pragma: Since I set the compiler to C++11, I suppose every compiler should support pragma once. But if this generate problems, we can always switch to the old, more verbose and compatible way, right?


• espaces/tabs: That is strange, because I used vim with expand tabs all the time. Thanks for the heads up, I'll check that!


• Destructos for race and class: I don't understand that. In fact, my plans for race and class is to be singleton, I just didn't had the time to search how to do it in C++ yet!


• espaces on include: Thanks, will fix that!


• this-> syntax: Yes, I like this better. people seems to often use _, mMyVariable or anything like that. I don't feel that is necessary any longer, since this-> already have all semantic you will ever need.


• getters: How would you do?


• using namespace: The only way I'm using it is on the tests. And I'm including my own namespace: d20! Does that still don't make sense for you?

 

Thank you both very much for taking the time to look at the code!

               
               

               
            

[Legacy_DrMcCoy]

               Maybe I'm missing something (and I've not tested it just now), but I don't see how a pure virtual class would prevent you from throwing a class pointer into a hashmap.
 

cmake can even use visual studio compiler

Sure, but when I want to create a Windows build on my GNU/Linux box with a MinGW cross-compiler, I'll have to manually fiddle with the CMakeList instead of just setting a few environment variables.

And CMake can't create Visual Studio project files on non-Windows, though, which I always found pretty stupid.

Me, what I'd ideally would like for my personal projects is a program that can parse my automake files and create Visual Studio project files out of them. This is similar to what ScummVM does.
 

pragma: Since I set the compiler to C++11, I suppose every compiler should support pragma once.

Just keep in mind that you're shutting out platforms with that (and with the reliance of C++11), like older versions of Mac OS X. Probably also the Nintendo DS and the PSP; at least from what I've seen in ScummVM, their toolchains are quite limited. Of course, it's entirely fine if you don't care about those.
 

Destructos for race and class: I don't understand that.

Well, your Character class stores a Race *, which might be a Human or an Elf or whathaveyou. If the ~Character() deletes the Race *, the Race destructor needs to be virtual. Otherwise, the Human/Elf/whathaveyou destructor won't be called and you're potentially leaking.

See also
http://www.parashift...tual-dtors.html
http://stackoverflow...ual-destructors
 

In fact, my plans for race and class is to be singleton

Ah, now I see where you're going with this. I don't think having singletons to represent the classes and races is such a good idea, to be honest.
 

I don't feel that is necessary any longer, since this-> already have all semantic you will ever need.

gcc and clang will still complain that you're shadowing the variables "name" and "race" in the constructor, though.
 

getters: How would you do?

I'd just do
 

Race *Character::get_race() {
  return race;
}

Since you're not shadowing anything there.
But, eh, like I said, I just don't like to use this-> anyway. *shrug*
 

using namespace: The only way I'm using it is on the tests. And I'm including my own namespace: d20!

Sure. I'd just prefix every with "d20::", but your choice.
               
               

               
            

[Legacy_Guest_TrillClinton_*]

               

A pointer of an abstract class should not change anything with the templates actually.

 

When you use <T>, what happens is that T generates a class at compile with type T. This T can be anything basically, the Race* should be able to work.

 

Lets take it for example your race is dwarf and your variable is initialized as R *dwarf;

 

dwarf->getRace(); will be able to get dwarf as long as it is virtual through V-tables.

               
               

               
            

[Legacy_virusman]

               

When you use <T>, what happens is that T generates a class at runtime with type T. This T can be anything basically, the Race* should be able to work.

Compile time, not runtime.

               
               

               
            

[Legacy_Guest_TrillClinton_*]

               

Compile time, not runtime.

 

 

Ah yes I made a mistake with that.

 

Virtual functions are runtime, template classes are compile time.

               
               

               
            

[Legacy_RedConfusion]

               

@DrMcCoy:

 

About building process: it seems to be possible to cross compile to windows with cmake. Setting the cross compiling variables I was able to generate a win file (with the wrong name!):

$ file _build/libd20.so
_build/libd20.so: PE32 executable (DLL) (console) Intel 80386 (stripped to external PDB), for MS Windows

However, I'm quite sure you have more experience than me on cpp, thus if you feel like changing cmake for custom scripts or whatever you think is best, I'll gladly accept!

 

About C++11 version: I think it is fine to ignore some old portable video games, and apple now releases its op for free. I have the lastest macos running on a macbook white. So I think we will be fine cutting support for old macos - we gain a better code and avoid a possible migration in the next years! The jump from c++11 to c++14 seems smaller compared to the previous ones.

 

 

I don't think having singletons to represent the classes and races is such a good idea, to be honest.

 

Can you elaborate? Don't forget I'm rusty on cpp!

 

I fixed the tabs, getters and setters and add a license. Thanks!

 

@TuringComplete

 

Ah, I see! I was avoiding using templates because of the compiling time and the cryptical error messages. But this might be related to my lack of experience. Maybe I should switch to a template? Will give a try. But now what is bugging me is the singleton thing.

 

@virusman:

 

I'm your fan. Thanks for maintain nwnx2!

               
               

               
            

[Legacy_Guest_TrillClinton_*]

               

@TuringComplete

 

Ah, I see! I was avoiding using templates because of the compiling time and the cryptical error messages. But this might be related to my lack of experience. Maybe I should switch to a template? Will give a try. But now what is bugging me is the singleton thing.

 

 

 

I don' think you should use templates for this. Only if it makes sense in the design. I only use templates when the class I am making can define a wide range of operations. Example is a binary tree. BinaryTree<T> the T would represent the different type of elements that can be maintained in the binary tree.

 

The map is already implemented as a template if I am not mistaken, so as long as you plug in the value that would be generated at compile time it is fine. Also, inheritance is fine but for game systems use composition if you can. It just makes it easier to work with. Use inheritance when you are sure that you can get a benefit from it. Inhertiance can cause a mess at times