The Arclight Project

For anyone interested (:laughing:):

The core rollnw library now supports the new EE GFF fields, i.e. visual transforms, per part coloring, expanded body parts, etc. So I feel safe to say now, with no false modesty, it’s easily the best post-EE NWN library, but… it’s a tools first project so stuff like nwsync which is irrelevant to building anything, has limited support.

I’m delaying work on the renderer since there are projects posted here that might serve as a better foundation. But there’s still a lot of widgets that can be made that are rather trivial. Ever wonder how you could make a NWN Toolset color picker? Barely 50 lines.

I’m now convinced property browser/views are the only way to go for anything that has any level of modability. NWN2 came to that conclusion as well, I think, after some weird fixed (they’re weird) widgets.

creature-view-appearance-2024-11-27.gif (The quality… of this webm->gif is bad)

It’s also clear to me, the game (NWN1 and NWN2) needs a NEW consortium, i.e. a diverse set of stake holders pushing the game forward in different ways (not just a diverse set of consumers, they are massively important too tho). A core library, netcode, renderer. Toolset, Server, Client, correspondingly. That resolves to something new. Not to dismiss the opinions of @clippy at all, but I feel a couple talented people, full time, could, with everything available today, do a NWN level engine in one year, especially disposing any needless backward compatiblity.

2 Likes

Full server+client (with toolset capabilities) implementation for scratch, with no backwards compatibility requirements (and no art assets)? Yeah, five skilled full time engineers for two years, plus support stuff. That comes down to about $2-3M, assuming the people work for below market rate because the project is cool. Anyone want to fund it? :money_mouth_face:

I am willing to change the name of this project from “The Arclight Project” to “The Community Arclight Project” to make this happen. :grin:

“From scratch” and “everything available today” are carrying a lot of weight in our respective sentences, but that’s something that we can elide for now.

Why would you want anyone to fund it? Get ambitious man. There’s like a million dollar industry around cartoons of g-man with his head in a toilet from Garry’s Mod. AAA games are at the lowest point they’ve ever been in our lifetime. A long road is not a bad one. Roblox came out not long after NWN, it’s still literal crap today and worth billions. (Luckily the people I know who love it can’t read this cause they’re 5)

The time to start is now. I could spin my pitchdeck today, you could too, and others as well. Beamdog is probably dead, so options are limited, I’ll grant that.

If someone know a skilled game dev engineer who will help part time in my project or only to suggest solution i’ll take him/her :slight_smile:
Returning to the argument … i don’t think that creating a “from scratch” project removing all the compatibility will be received well from the community. We all are here because the NWN and NWN2 compatibility with all the awesome modules, campaign, scripts and other mods that people create for this projects so new one? Mmmm if you want to create a new one you will need to create a NWN3 with modern graphics, with modern ruleset and with modern features so … i don’t think $2-3M will be enought … Oops, but a similar project already exists and it’s called BG3 and from what I know it was created in 5-6 years and cost >$100M.

1 Like

We’ve gone a bit off field with this and are talking about different things. Larian Studios is great example tho of the slow grind, Swen had a vision and have iterated on it over almost 30 years!, that plus selling a chunk to tencent allowed them to spend 100m on BG3. “One cannot fly in to flying”. That’s what allows that, not pie in the sky, not looking “cool” on Discord, but serious hard work.

For anyone interested (:laughing:), after seeing @Maiyannah post about palettes, I decided to dust off / finish up some features in the rollnw library. Even tho it’s not the direction the project ultimately wants to go as discussed above, it’s still necessary to support.

In the case of a palettes, a very basic JSON or text format is the best way to go. Their staticness and use cases don’t require any performance considerations, imo. Here is a skeleton palette example:

{
    "$type": "ITP",
    "$version": 1,
    "next_available_id": 3,
    "resource_type": "utc",
    "root": [
        {
            "name": "The Office",
            "strref": 1,
            "|children": [
                {
                    "id": 0,
                    "name": "Bears",
                    "strref": 2
                },
                {
                    "id": 1,
                    "name": "Beets",
                    "strref": 3
                },
                {
                    "id": 2,
                    "name": "Battlestar Galactica",
                    "strref": 4
                }
            ]
        }
    ]
}

It follows the same structure as the gff ITP format: categories (that can contain blueprints) have an ID, branches that can contain other branches and categories do not. Note: obviously custom tlk entries are need in this example.

I’ve added a palette notebook

This is one of the cases where I don’t believe programmatically editing a Palette object is worth the effort vs programmatically editing json or a python dict and converting that to a Palette then to GFF. Editing by hand would always be the best choice, regardless.