Add milestones or state of the re-implementation

[nicman23]

Hello, I just found this project and it is not clear from README.md or the Wiki in what state the engine is and its playability

While Change logs are fine for anyone familiar with the project, for the end user mean little.

So what is the state of the project?

[667bdrm]

It is not yet playable. There are lot of things that needs to be implemented: full scripting support, worldmap, combat ai, npcs, barter, elevators, skills, etc. You currently able to walk on the map and doing some interaction. You could look at YouTube videos

[prokopst]

I have to say that state of the project is very unclear to me as well. Is there a stable team of people behind it? Doesn't seem so. Is it randomly alive and dead? More likely.

What makes me sad is that I would love to contribute to the project but for me C++ is no-go.

Don't get me wrong, I think I understand C/C++ well (at least prior C++14). But that's the problem, I understand it well enough to know that C++ is not the most efficient programming language to use especially when raw pointers are used all over the place with unclear ownership of allocated memory. Hello segmentation faults? #530 #531 #538

I do appreciate what all maintainers and contributors achieved, but I think that the lack of any public relations (or how to call it?) and the choice of the programming language + the approach (raw pointers) is a blocker to attract new developers and to make the project alive.

It's all my opinion, don't lynch me for that.

(I noticed this thread from a discord notification)

[adamkewley]

@prokopst , I can understand your frustration, but keep in mind:

• It's a remake of an absolutely massive AAA game
• Which was buggy, even when it was initially developed by a paid team containing some of the best RPG game developers available in the late 90s
• Where the assets are now only available in binary form and need to (e.g.) be reverse-engineered through a virtual machine
• Where, even though it's currently lacking, it's already ~30 kLOC of C++, putting it in "large project" territory
• Commits have been made to this repo over a timespan of 5 years (as far as GitHub shows) with off-and-on, but consistent over the long-term, commits
• ~80 % of what's in the master branch was produced by one (presumably unpaid) developer, @alexeevdv

As for C++ being a "no go", I don't personally understand what language you'd consider to be a "go". Large game engine projects benefit from:

• Static typing: because refactoring a >5 kLOC codebase without typing is hell
• Strong standard library: because reimplementing lists, trees, algorithms, etc. cleanly is a waste of time
• Powerful language features (lambdas, templating, moving, templating, etc.): because every complex project will end up with codegen sooner or later
• Libraries

There's a reason why many games are written in C++ and it isn't entirely because of tradition. It's got a nice blend of pragmatism, speed, power, and abstraction. This makes it good for complex projects (e.g. game engines, compilers, AI, self-driving cars) but makes it poor for simpler projects (webapps sitting on an SQL database). The fact that you see using the most popular game engine programming language--apart from, maybe, C# with Unity engine (which, itself, is written in C++)--as a "blocker" is a pretty unfair constraint to place on a 5 year old, free remake of a major AAA game.

[prokopst]

but keep in mind

20 years ago the technical challenges were quite different - toolsets, debug-ability , access to information and trainings. The scale of projects has changed too. You can't compare what was achieved by N game developers 20 years ago and now. That's vastly different. Note I don't say it's not a large project. It is.

As for C++ being a "no go" ...

I think you missed the part with the raw pointers:
"C++ is not the most efficient programming language to use especially when raw pointers are used all over the place with unclear ownership of allocated memory"
Raw pointers means dangling pointers and segmentation faults. Large projects use smart pointers. Unreal has them and it even uses garbage collection for its UObjects. Its C++ is full of magical macros, it actually feels like a different language to be honest.

There's a reason why many games are written in C++ ...

From code perspective the games nowadays consists are made of two things:

• a game engine like Unity which handles physics, graphics, event handling and dictates the structure of your components (Entity components, scene graph)
• the game itself (user interface, inventory handling, reaction to collisions, ..., sometimes even path finding)

Besides many others Unity powers these games, so they are written in C# - Wasteland 2, Torment: Tides of Numenera, Tyranny.

For you it might sound unfair, for me (based on my experience!) it sounds like investing into bug hunting sessions full of dangling pointers written in a language which has a smaller pool of potential developers than for example C# (or maybe even Rust).

The owner of the project should not take it as criticism of the past decisions, I think that 5 years ago C++ was a reasonable choice and raw pointers were usually fine for smaller projects.

I'm just stating my rationale, that's it.

[Oppen]

From code perspective the games nowadays consists are made of two things:

* a game engine like Unity which handles physics, graphics, event handling and dictates the structure of your components (Entity components, scene graph)

* the game itself (user interface, inventory handling, reaction to collisions, ..., sometimes even path finding)

Can the scripting language and its "VM" and codecs for assets be implemented in the second layer? Because that's a must for falltergeist, otherwise it can't be compatible with the original Fallout.

For you it might sound unfair, for me (based on my experience!) it sounds like investing into bug hunting sessions full of dangling pointers written in a language which has a smaller pool of potential developers than for example C# (or maybe even Rust).

Off-topic, but I don't think there are too many Rust programmers, let alone experienced ones. While it seems to be a great language and it deserves its respects, it's still young and thus it's probably not adopted enough.

[alexeevdv]

Greetings! This project has started as my attempt to learn C++. My everyday work is related to backend web development which implies of using weakly typed languages like PHP, JavaScript, Python, etc... Even now after all these years C++ is quite hard language for me to understand (and i dont even talk about all that templates meta programming)

Current project status is pretty simple: i dont have any time for it. I hope one day i'll have more free time which i could spend on this project. But so far cant do it currently. Feel free to ask if you have any more questions

[prokopst]

Can the scripting language and its "VM" and codecs for assets be implemented in the second layer? Because that's a must for falltergeist, otherwise it can't be compatible with the original Fallout.

@Oppen Yes, you can do it using the standard libraries of for example C# and even Python, nothing extra is required (you handle binary protocols in C# using StructLayout). The only drawback using Python is definitely performance (which can be solved by using things like Cython, but that complicate things a little).

In theory the original Fallout assets can be "just" converted into more open formats (like MAP into tiled, scripts recompiled into something else) to allow moders to resurrect the original Fallouts in a friendly way. In theory, there are definitely many challenges for this solution.

Off-topic, but I don't think there are too many Rust programmers, let alone experienced ones. While it seems to be a great language and it deserves its respects, it's still young and thus it's probably not adopted enough.

That's a fair point and I agree - Rust wouldn't actually be a good choice now. Probably whatever written in Rust is very visible in the small Rust community itself, but not that much out of its own community.

[nicman23]

Cython

in my experience does not really make any difference (at least if you do not constantly needed to reinit the script) although I only worked with it on some very specific simulation work

[adamkewley]

@prokopst , I apologize if I came off as confrontational. It's just that I've personally wanted an open-source F1/2 port for a long time and, whenever I've looked into the state of affairs (what's out there, etc.) it seems that this project is the most comprehensive attempt up to now.

I agree that C#/Python might've been more approachable for new developers, but if the main problem with hacking on this codebase is that it contains (e.g.) raw pointers and some hacky tricks then we could use that problem as an opportunity to submit a few pull requests containing incremental smart pointer refactors.

The main issue I see with this project is whether @alexeevdv has the time to review + merge PRs into this repo and, accordingly, whether contributors are willing to fix the problems with pull request. I completely sympathize with the problem of keeping something this big continually updated when: a) noone's paying and b) noone's contributing.

[alexeevdv]

Pull requests are always welcome but i cant guarantee immediate reaction

[667bdrm]

@alexeevdv, I think you have made very good project architecture, it is easy to understand it and modify (of course if you have developed in c++ for a little :)

[prokopst]

@adamkewley I think we all here are on the same side, we desire to have an open-source port.

I'm sure that replacing raw pointers to properly owned pointer wrappers from std (std::weak_ptr, std::unique_ptr, std::shared_ptr) would make the code safer, that's for sure. There is a cost though, it would increase the code complexity though.

And still C++ is IMO a big barrier to newcomers thanks to a steep learning curve. Unfortunately I don't see a clear way out of it.

[Oppen]

The only drawback using Python is definitely performance (which can be solved by using things like Cython, but that complicate things a little).

I don't think performance would be that much of a problem, the original engine ran on computers less powerful than today's phones, so the performance hit of implementing it with a higher level language should be negligible.

In theory the original Fallout assets can be "just" converted into more open formats (like MAP into tiled, scripts recompiled into something else) to allow moders to resurrect the original Fallouts in a friendly way. In theory, there are definitely many challenges for this solution.

That's actually a better idea IMO. I saw this path taken on different reimplementations of games, I wonder why it didn't cross my mind before.
Also, this way we can have a more gradual, yet visible, improvement. You only have to work in a format converter at a time. The glue for converting the whole at a time should be rather simple.

[adamkewley]

Putting the IO formats into a separate shared library with a C API could be an idea. There might be some merit to:

• Grabbing the IO code from this repo
• Refactoring it
• Publishing a C ABI to it

That way, other devs could separately integrate (e.g.) python utils, GUIs, editors, converters, etc. around it.

The current build for this repo could be refactored into a multi-project CMake thing that builds all of this as part of the project, so we don't end up with two repos for Fallout IO. I could look into it when I get a spare evening (rare)

[alexeevdv]

We had separate lib for Fallout formats before. But lib itself was quite messy and it was hard to manage engine and lib the same time. That is why lib was included in engine code later

https://github.com/falltergeist/libfalltergeist

[adamkewley]

Ah, I can see how that would be a pain if the two are separate and you are hacking on the engine a lot.

Maybe a middle ground would be to put turn this one repo into a multi-project CMake build where you have:

• falltergeist
• libfalltergeist-io (or something)

From what I remember with my toy projects, you can configure CMake to build projects separately but link them together properly at run/compile-time. IIRC, I did this to run GoogleTest (C++) unit tests against a C library.

When built like that, you can play with the code in-branch (it's still in the repo dir) and the IDEs etc. will still recompile things accordingly whenever you debug but, because they're separate CMake projects, you can have the IO project built + deployed separately later down the line (e.g. as a shared object).

I do something simliar with java projects (e.g.) where there's a collection of separate--but interdepenent--builds (docs, packages, executables) but they are all in one tree, so there isn't the PITA of having to re-tag and re-deploy a separate repo.

[adamkewley]

I'll fork this and try to refactor the build to reflect what I'm saying. If I can do it, I'll push a PR here so you can play with it and see if it works well for your dev workflow (some IDEs may be more annoying than others about it).

[adamkewley]

Just to keep the idea of devs being able to hack at, for example, python libraries. I have created a PR which demos separating Falltergeist's IO into a shared object. The structure means that everything is still in this repo but the build also produces a library that downstream devs could use to build (e.g.) file converters (e.g. as @prokopst mentioned, for grid files).

The overall implementation is slapdash--I only had one evening to do it--but should demonstrate the general idea. Later improvements would be to expose a C API to the IO library so we can start wrapping python libs around it etc.

[phobos2077]

@prokopst I'm not sure what are the alternatives to C++? If you want to use different language it'll probably be a different project entirely. Or you can use pieces of Falltergeist as a set of native DLLs and then link with them from other language. I actually debated in the past to use Lua as a main language for all high-level game logic, with C++ parts being responsible for low-level things like rendering, audio, resource management, main loop, etc. But later Lua integration was removed sadly due to lack of time on my part to properly integrate it (some team members decided it was impeding progress and it was more productive to focus on single language implementation, thus reducing the need of integration between two languages).

The code with raw pointer usage you refer to is mostly legacy code, the later code we wrote used C++14 approach with smart pointers etc. but I guess not everything was converted yet. This is mainly due to the lack of understanding of how to design ownership in modern C++ within the team.

Regarding the state of project, a few years ago we had a very small but relatively active team, but due to lack of time and some disagreements the team is now basically non-existent. I would be really happy to see somebody with strong C++17 knowledge and experience with game engines take over, make a fork and continue where we left of (finish refactoring to proper C++, decide on architecture to build game logic on). The goal IMO is to finish the foundation for other less hardcore C++ programmers to fill in the blanks. I had a lot of suggestions for improving the architecture back in the day, you can check them out in the issue section.

About the scripting support, actually we went quite far in this regard as a lot of opcodes are already implemented and you can even interact and have dialogue with some NPCs.

[adamkewley]

@phobos2077 what's there is already impressive just because the project is quite difficult: there's so much reverse engineering required to make things backwards-compatible with the original assets.

w.r.t C++17, I'm currently trying to add C++17 on the fork I used for the above PR, for example, renaming the namespaces to C++17 style:

https://github.com/adamkewley/falltergeist/commit/401b18efa688be22dcc992c96b0af84602f0d85f

When doing that I encountered a minor issue with C++17: many distros/OSes don't fully support it yet with their standard package managers, which is what's breaking travis CI on the fork. A bigger issue I encountered is that using C++17 could significantly narrow the potential user pool because many distros don't even have a C++17-compliant runtime library (e.g. libstdc++). For that reason, I'm probably going to downgrade my pet fork back to C++14, just to ensure I'm not creating problems when it comes to deploying the binaries.

I can submit PRs upstream if you'd like, but I'm mostly focusing on learning how to structure and refactor C++ projects. I mostly work in Java/python/javascript professionally, but I'm about to switch to C++.

I'm probably going to focus on cleaning up the IO libraries in preparation for publishing them with a C API that other hackers could study/use. I'm keeping the library in the falltergeist tree so that it can be built alongside it, but separately from the engine. I'm a bit afraid to refactor the game engine unless there's regular pulls/updates on the master repo because there's plenty of places I could collide with other devs and, therefore, I risk creating a merge nightmare.

[mbloody]

Look at http://www.fifengine.net. It was started as open source Fallout engine, but....
Currently FIFE yet another game engine with lot of features but is not Fallout.

[phobos2077]

@mbloody FIFE is ancient and don't think it can read FO assets like Falltergeist can. This project is the closest to Fallout 1/2 remake that I'm aware of.

[JanSimek]

I think the point @mbloody was making is that FIFE team kept adding new features unrelated to the Fallout engine and constatly "improving" the codebase like rewriting the high-level stuff from C++ to Python. They got derailed from making the actual game work. Eventually, support for Fallout assets was removed from FIFE altogether.

[alexeevdv]

@adamkewley lets stick to C++14 for now

[JanSimek]

@prokopst it looks like someone was inspired by your idea of reimplementing this engine in Rust: https://github.com/pingw33n/vault13

[alexeevdv]

Looks promising. Lets wish that project a good luck :)

[JanSimek]

That's one of the major milestones done #633

diff --git a/README.md b/README.md
index 99c8fd03..520bf2ee 100644
--- a/README.md
+++ b/README.md
@@ -67,7 +67,6 @@ or mount CD-ROM with original game, then run `./falltergeist` on \*nix or `.\bin
 This is a pretty highlevel roadmap to get to a playable game. The idea behind it is to step by step get closer to the full game.
 
 - Worldmap support
-- Elevators
 - NPCs
 - Combat AI
 - Full scripting support

[clort81]

Sitting on the sidelines for many years now, wishing the developers all the best.